Как выполняется множество клиентских подключений к одному веб-серверу?

На самом деле я изучаю компьютерные сети, и в то же время я не понимаю, как веб-сервер поддерживает несколько соединений?

Проще говоря, я узнал, что в результате некоторого поиска в Google сокеты обрабатывают каждый запрос клиента.

Допустим, есть веб-сервер и, скажем, 2 клиента с IP

Client A: 5.5.5.5
Client B: 10.10.10.10 

Они оба пытаются подключиться к серверу через порт 80.

Теперь, от поиска в Google, сервер прослушивает порт 80 на предмет входящих запросов. Затем допустим, что клиент А пытается подключиться к серверу (установить соединение TCP / IP). Во время которого создается сокет между этими двумя. Затем он выполняется как отдельный поток для дальнейшей связи, заставляя сервер снова прослушивать запросы других клиентов на этом конкретном порту. И Клиент Б подключается так же.

Теперь мой первый вопрос:

1. How does server communicate with these two clients simultaneously  
   after the connection has been established?

Теперь к серверу могут подключиться практически не 2 клиента, а тысячи и миллионы пользователей.

Тогда мой следующий вопрос:

2. Now, how do those thousands of clients get connected to a single server?

   If we assume every client is connected to the server through wire, it is not 
   practically possible to maintain that many sockets on a hardware for
   connection. How those thousands connections are made and handled?

И наконец, мой третий вопрос:

3. Above I said (actually heard) how **client A** connected to the the server
   and similarly the client B.

   But I didn't get the part stating "after a TCP/IP connection is made they
   continue separately in a separate socket and making server to listen for 
   other client requests." What does that mean? If one client is communicating
   to the server, how come other can communicate at the same time to same server.

   Isn't it like while a student is asking question to a teacher, other can't
   ask at the same time since that particular student is busy or occupying the
   teacher at the moment so others should wait, which we compare than client B 
   should wait when client A is communicating.

Это мои основные вопросы, которые я не получаю. Пожалуйста, поправьте меня, если я все понял неправильно. Вы можете предложить мне некоторые книги / PDF-файлы для чтения, если ответы детализированы или не сфокусированы на конкретной части. Благодарность

Теперь, от поиска в Google, сервер прослушивает порт 80 на предмет входящих запросов.

Более конкретно, существует специальный тип сокета, называемый «слушающим» сокетом.

Обычно сокет связан с комбинацией локального IP, локального порта, удаленного IP и удаленного порта.

Разъем для прослушивания отличается. Он не связан с каким-либо конкретным удаленным IP-адресом и портом. Он связан с конкретным локальным портом. Это может или не может быть связано с определенным локальным IP.

Обычно ваш веб-сервер имеет сокет прослушивания с локальным портом 80

Затем допустим, что клиент А пытается подключиться к серверу (установить соединение TCP / IP). Во время которого создается сокет между этими двумя.

Пара сокетов фактически одна на клиенте, другая на сервере.

Клиентское приложение создает сокет и просит клиентскую ОС подключить его к серверу.

Клиентская ОС выделяет случайный локальный порт, выбирает локальный IP-адрес (обычно в зависимости от того, на каком интерфейсе будет отправлен пакет) и заполняет удаленный IP-адрес и порт, запрошенные клиентским приложением. Затем начинается процесс подключения к серверу.

Операционная система сервера уведомляет держателя прослушивающего сокета о том, что устанавливается новое соединение. Серверное приложение принимает соединение, и для его обработки создается новый сокет.

Несколько потоков или даже процессов могут контролировать один и тот же сокет листинга. ОС гарантирует, что именно один из них получит данное соединение.

Затем он выполняется как отдельный поток для его дальнейшего сообщения.

Это зависит от разработчика серверного приложения. Они могут выбрать использование нескольких потоков или использовать API, например «выбрать» или «опрос», который позволяет одному потоку отслеживать активность нескольких сокетов.

1. Как сервер взаимодействует с этими двумя клиентами одновременно
   после установления соединения?

ОС сервера будет сопоставлять пакеты с сокетами по комбинации IP-адреса источника, исходного порта, IP-адреса назначения и порта назначения и доставлять их в соответствующий сокет.

2. Теперь, как эти тысячи клиентов подключаются к одному серверу?

   Если предположить, что каждый клиент подключен к серверу по проводам, практически невозможно поддерживать такое количество сокетов на оборудовании для подключения. Как эти тысячи соединений сделаны и обработаны?

«Сокет» в этом контексте относится не к физическому сокету, а просто к структуре данных в операционной системе.

Тем не менее, существуют ограничения, тысячи легко осуществимы на современном сервере, миллионы становятся трудными.

Разве это не похоже на то, что когда ученик задает вопрос учителю, другие не могут спрашивать в то же время, так как этот конкретный ученик в данный момент занят или занимает учителя, поэтому другие должны ждать, что мы сравниваем, а клиент B должен ждать когда клиент А общается.

Компьютеры гораздо лучше разделяют свое внимание, чем люди. Очевидно, что если сервер имеет только одно процессорное ядро, он может делать только одну вещь за раз, но если он может переключаться между вещами достаточно быстро, клиенты не заметят этого.

И, конечно, в настоящее время многие серверы имеют несколько процессорных ядер.

Создается новое соединение, а не сокет. Я думаю, что вы расширяете заблуждение ОП о том, что такое сокет.

Кажется, проблема в том, что rfc отличается от реальной практики определением сокета.

Я просто пошел и посмотрел документацию для "accept" для трех основных операционных систем, все они рассказывают о принятии создания нового сокета.

http://man7.org/linux/man-pages/man2/accept.2.html

https://www.freebsd.org/cgi/man.cgi?query=accept&sektion=2

https://msdn.microsoft.com/en-us/library/windows/desktop/ms737526%28v=vs.85%29.aspx