(У меня вопрос о подтверждении связи TCP и о том, как назначаются номера портов, если это не относится к этому, дайте мне знать.)
Привет, я изучаю TCP / IP из книги Дугласа Комера «Межсетевое взаимодействие с TCP / IP». В главе о TCP упоминается, что TCP определяет «конечную точку» как пару (IP-адрес, номер порта), а соединение определяется двумя конечными точками.
Это имеет несколько последствий, например, локальный TCP-порт может находиться в нескольких соединениях одновременно, если нет двух с одинаковым IP и одним и тем же удаленный порт. Это также означает, что количество установленных подключений практически безгранично (2 ^ 16 на каждый IPv4-адрес. Всего 2 ^ 48).
Теперь в классе мне сказали, что, когда кто-то подключается к порту прослушивания, обе стороны соглашаются использовать другой порт, поэтому связь может происходить, а сокет слушателя остается свободным. В это я тоже верил до чтения книги.
Теперь я чувствую, что, очевидно, должен доверять книге (это Comer!), Но есть ли правда в другом объяснении?
Спасибо
Во-первых, основы - сокет - это 4-кортеж из (srcip, srcport, dstip, dstport). Если любое из этих значений изменится, это другой сокет. Когда данный хост открывает сокет TCP (или UDP, если на то пошло), его исходный IP-адрес уже известен, исходный порт выбирается случайным образом из эфемерного диапазона (больше 1023 или 1024 - забудьте какой), а также IP-адрес и порт назначения. передаются в стек вызывающим процессом.
На стороне сервера устанавливается соединение, которое поступает из заданных srcip и srcport и привязано к dstport и dstip. Эта запись (опять же - некая 4-кортеж) хранится в таблице соединений хоста, что позволяет связать входящие пакеты с соответствующим соединением.
Подтверждение связи TCP - это процесс, с помощью которого стеки TCP на соответствующих сторонах согласовывают параметры порядковых номеров, размеров окон и т. Д. К тому времени, как это произойдет, номера портов уже определены.
Опять же - если любой значений в этих кортежах изменяется после первоначального соединения, то, по определению, пакеты больше не связаны с исходным сокетом.
Существуют определенные обстоятельства, при которых другие номера портов могут быть указаны используемым приложением (например, FTP, RPC), но во всех случаях это требует создания отдельный сокет, а не перенумерация существующего. В случае FTP это будет соответствовать начальному соединению через порт 21 (управление) от хоста -> сервера, а затем последующему соединению через порт 20 (данные), которое, в зависимости от используемого режима, может быть установлено в любом направлении. . Я не могу особо подчеркнуть, что это два отдельных сокета. Возвращаясь к стеку OSI, это будет проблемой пятого уровня.
Нет, другое утверждение не соответствует действительности. Вы, вероятно, принимаете это за активный FTP.
локальный TCP-порт может быть одновременно в нескольких соединениях
Да - чтобы клиенты найти сервис, то он всегда запускается на определенном порту на сервере - 80 для HTTP, 25 для SMTP, 22 для ssh ... Веб-сервер будет иметь множество клиентов, подключенных к его порту 80.
Теперь в классе мне сказали, что когда кто-то подключается к слушающему порту, обе стороны соглашаются использовать другой порт.
Либо вы, либо ваш учитель не понимаете, что происходит. Есть несколько протоколов, в которых клиент и сервер будут согласовывать разные сокеты - соединение для передачи данных FTP, некоторые формы rpc и (IIRC) ранних версий Oracle sql * net работали таким образом, но это ОЧЕНЬ необычно.
Ваш учитель - это тот, кому платят за то, чтобы он понял проблему и ответил на ваши вопросы - я предлагаю вам вернуться к нему / ей.
Это определенно не по теме Server Fault, но у вас ужасное недоразумение, которое требует исправления :-)
Во-первых, вы можете отказаться от книги Comer, в которой они находятся, и взять копию Иллюстрированный TCP / IP (Стивенс) - это во многом личное предпочтение, но все, кого я знаю, предпочитают книгу Стивенса.
Теперь к сути вашего вопроса:
TCP определяет «конечную точку» как пару (IP-адрес, номер порта), а соединение определяется двумя конечными точками.
Это концептуально правильно. какой на самом деле происходит на уровне протокола немного отличается, но концепция TCP-соединения состоит в том, что клиент (например, ваш веб-браузер) открывает локальный сокет (10.0.0.1 порт 30000) и подключается к серверу (10.10.10.10 порт 80) .
Соединение - это канал между этими двумя конечными точками.
Теперь в классе мне сказали, что, когда кто-то подключается к порту прослушивания, обе стороны соглашаются использовать другой порт, поэтому связь может происходить, а сокет слушателя остается свободным.
Это наполовину правильно - похоже, что то, что вы пытаетесь описать, является запутанной версией поведения rendezvous socket прослушивание на сервере.
Как вы догадались, если у нас будет связь только через сокет рандеву, только одна машина сможет подключиться к данному слушателю за раз (что отчасти бесполезно), поэтому на самом деле происходит то, что сервер accept()s соединение TCP-стек на стороне сервера передает новый подключенный сокет, на котором происходит фактический диалог.
Для всех кровавых подробностей см. Книгу Стивенса, для более краткого описания. попробуйте этот вопрос StackOverflow.
Если вы хотите небольшой урок истории, это видео вероятно, будет вам интересен (время, отмеченное закладкой в этой ссылке, примерно там, где начинается обсуждение TCP, но все видео или серия из трех частей - это то, что любой серьезный студент компьютерных наук, который изучает дизайн ОС и / или сети надо смотреть).