套接字编程 - 为什么Web服务器仍然使用listen端口80与客户端进行通信，即使他们接受了连接？

Question

通常，Web服务器通过端口80监听任何传入连接。所以，我的问题是，不应该是套接字编程的一般概念是端口80用于监听传入连接。但是在服务器接受连接之后，它将使用另一个端口，例如端口12345来与客户端通信。但是，当我查看wireshark时，服务器在通信期间始终使用端口80。我在这里很困惑。

那么如果https://www.facebook.com:443，它会在一秒钟内与它成千上万的连接。单个端口是否可以处理如此大量的流量？

Answer 1

特定套接字由5元组唯一标识（即5个特定属性的列表。）这些属性为：

1. 来源IP地址
2. 目标IP地址
3. 源端口号
4. 目的地港口号
5. 传输协议（通常为TCP或UDP）

对于同时打开的套接字，这些参数必须是唯一的。在这里你可能会感到困惑的是客户端发生的事情与TCP中服务器端发生的事情。无论有问题的应用程序协议（HTTP，FTP，SMTP等等），TCP的行为方式都相同。

当您在客户端打开套接字时，它将为新的传出连接选择一个随机的高位端口。这是必需的，否则您将无法在同一台计算机上打开两个单独的套接字到同一台服务器。因为想要这样做是完全合理的（并且在Web服务器的情况下非常常见，例如在两个单独的选项卡中打开stackoverflow.com）并且每个套接字的5元组必须是唯一的，随机的高数字端口用作作为源端口。但是，每个套接字都将连接到stackoverflow.com的网络服务器端口80。

在服务器方面，stackoverflow.com已经可以再次区分客户端的这两个不同的套接字，因为它们已经有不同的客户端端口号。当它从浏览器中看到传入的请求数据包时，由于源端口号不同，它会知道它打开了哪些套接字来响应。同样，当它想要向您发送响应数据包时，它可以通过将目标端口号设置为它从其获得请求的客户端端口号将其发送到您身边的正确端点。

最重要的是，每个客户端连接在服务器端都没有单独的端口号是不必要的，因为服务器已经可以通过其客户端IP地址和客户端唯一地标识每个客户端连接 - 侧口号码。无论应用层协议如何，这都是TCP（和UDP）套接字的工作方式。

Answer 2

  

一般来说，套接字编程的概念不应该是端口80用于监听传入连接。但是在服务器接受连接之后，它将使用另一个端口，例如端口12345与客户端通信。

没有

  

但是，当我查看wireshark时，服务器在通信期间始终使用端口80。

是

  

我在这里很困惑。

只是因为你的一般概念＆＃39;不正确。接受的套接字使用与侦听套接字相同的本地端口。

  

那么如果https://www.facebook.com:443，它会在一秒钟内与它成千上万的连接。单个端口是否可以处理如此大量的流量？

端口只是一个数字。它不是物质的东西。它没有处理任何事情。 TCP基于元组{源IP，源端口，目标IP，目标端口}来识别连接。只要整个元组是唯一的，就没有问题。

Answer 3

端口是一个虚拟概念，而不是硬件资源，在1个端口上处理10 000个连接并不比10 000个端口上的1个连接更难（甚至可能要快得多）

Answer 4

并非所有服务器都是在端口80上侦听的Web服务器，并非所有服务器都保持持久连接。特别是Web服务器是无状态的。

您打开新端口进行进一步沟通的建议正是使用FTP protocol时所发生的情况，但正如您所见，这是没有必要的。

端口不是物理概念，它们以标准化形式存在，允许在没有专用多路复用软件的情况下在同一主机上访问多个服务器。这样的软件仍然存在，但原因完全不同（参见：sshttp）。您在端口80上看到服务器的响应，服务器在操作系统分配您的连接的不那么随机的端口上看到您的回复。

Answer 5

当服务器侦听套接字第一次接受TCP请求时，Socket java.net.ServerSocket.accept()之类的函数将返回一个新的通信套接字，其端口号与相同作为来自{的端口{1}}。 这是屏幕截图。