HTTP 响应如何找到正确的浏览器窗口?
如果您打开了两个浏览器窗口,并且使用每个窗口导航到不同的网站,那么软件如何知道哪个 HTTP 响应属于哪个浏览器实例?
更新
看来区别是由入站 TCP 端口号决定的。但是不涉及 TCP/UDP 的网络消息又如何呢?例如,如果您打开两个终端应用程序并使用两者向同一远程服务器发送 ping 消息,则回复如何找到到达其终端实例的路径?
If you have two browser windows open and you use each to navigate to a different website, then how does the software know which HTTP response belongs to which browser instance?
Update
It seems that the distinction is made by the inbound TCP port numbers. But what about network messages that don't involve TCP/UDP? For example, if you open two terminal applications and use both send a ping message to the same remote server, how does the reply find its way to its terminal instance?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
通常,每个浏览器实例都会创建自己的 socket 来与服务器通信。虽然所有套接字的出站端口相同(通常是 TCP 80 或 443),但它们的入站端口不同。因此,当服务器响应请求时,不会发生冲突,因为响应被发送到不同的入站端口。
像
ping
这样的工具使用 ICMP 数据包,它们提供了自己的方式唯一标识调用应用程序(唯一标识符和序列号)。Typically, each browser instance creates its own socket to communicate with the server. Though the outbound port of all the sockets is the same (usually TCP 80 or 443), their inbound ports are different. Thus, there are no conflicts when the server responds to the requests, since the responses are sent to different inbound ports.
Tools like
ping
use ICMP packets, which provide their own way to uniquely identify the calling application (a unique identifier and a sequence number).它们通常与不同的 TCP 连接相关联,这些连接在客户端上使用不同的端口。这意味着客户端的 TCP 堆栈知道不同之处,并通过客户端使用的套接字 API 以易于区分的方式传递它们。 (通常是不同的文件描述符)
例外是管道传输,作为一种优化,可以通过一个连接发送多个 http 请求。然而,像这样发送的请求会按照发送的顺序接收,因此将它们与请求进行匹配变得很简单。
They're usually associated with different TCP connections, which between them have used different ports on the client end. This means that the TCP stack at the client end knows the different and passes them via the sockets API the client used in an easily distinguishable way. (Typically different file descriptors)
The exception to this is pipelining where multiple http request can be sent over one connection, as an optimisation. Requests sent like this are received in the order they were sent however, making it trivial to match them to the requests.