Web 中的 TCP/IP 是如何工作的？一个数据包是如何正确传达到目标主机对应程序中的？

互联网，实际上是一套理念和协议组成的体系架构。其中，协议是一套众所周知的规则和标准，如果各方都同意使用，那么它们之间的通信将变得毫无障碍。

了解一下OSI七层模型和TCP/IP协议的关系：

TCP/IP是一组协议的代名词，包括许多别的协议，组成了TCP/IP协议簇。
TCP/IP是基于TCP和IP这两个最初的协议之上的不同通信协议大的的集合。
TCP/IP四层模型 则是合并数据链路层以及物理层为网络接口层。

一个数据包的旅程

互联网中的数据是通过数据包来传输的。如果发送的数据很大，那么该数据就会被拆分为很多小数据包来传输。

IP：把数据包送达目的主机

数据包要在互联网上进行传输，就要符合网际协议（Internet Protocol，简称 IP）标准。

计算机的地址就称为 IP 地址，访问任何网站实际上只是你的计算机向另外一台计算机请求信息。

---

📌主机A 从 站点A（应用程序）向 主机B 的 站点A（应用程序）发送数据包：

一个数据包从主机 A 到主机 B 的旅程：

• 上层将含有站点A数据的数据包下发到网络层
• 网络层将IP头附加到数据包上，组层新的IP数据包，并交给底层
• 底层通过物理网络将数据包传输给主机 B；
• 数据包被传输到主机 B 的网络层，在这里主机 B 拆开数据包的 IP 头信息，并将拆开来的数据部分交给上层；
• 最终，含有站点A信息的数据包就到达了主机 B 的上层了(注意只是上层，并未具体到哪个应用)。

UDP:把数据包送达应用程序

IP是个很基础（底层）的协议，只负责将数据包传到对应主机，但不知道要将数据包传给那个应用程序。因此，需要基于IP 之上开发能和应用打交道的协议，最常见的是UDP（用户数据包协议）。

UDP 中一个最重要的信息是端口号，每个想访问网络的程序都需要绑定一个端口号。通过端口号 UDP 就能把指定的数据包发送给指定的程序了。IP 通过 IP 地址信息把数据包发送给指定的电脑，而 UDP 通过端口号把数据包分发给正确的程序。

一个数据包从主机 A 到主机 B 的旅程：

• 上层将含有站点A数据的数据包下发到网络层
• 传输层会在数据包前面附加上 UDP 头，组成新的 UDP 数据包，再将新的 UDP 数据包交给网络层；
• 网络层再将 IP 头附加到数据包上，组成新的 IP 数据包，并交给底层；
• 数据包被传输到主机 B 的网络层，在这里主机 B 拆开 IP 头信息，并将拆开来的数据部分交给传输层；
• 在传输层，数据包中的 UDP 头会被拆开，并根据 UDP 中所提供的端口号，把数据部分交给上层的应用程序；
• 最终，含有“站点A”信息的数据包就旅行到了主机 B 上层应用程序这里。

在使用 UDP 发送数据时，有各种因素会导致数据包出错，虽然 UDP 可以校验数据是否正确，但是对于错误的数据包，UDP 并不提供重发机制，只是丢弃当前的包，而且 UDP 在发送之后也无法知道是否能达到目的地。

UDP 不能保证数据可靠性，但是传输速度却非常快，所以 UDP 会应用在一些关注速度、但不那么严格要求数据完整性的领域，如在线视频、互动游戏等。

UDP 来传输会存在两个问题

• 数据包在传输过程中容易丢失；
• 大文件会被拆分成很多小的数据包来传输，这些小的数据包会经过不同的路由，并在不同的时间到达接收端，而 UDP 协议并不知道如何组装这些数据包，从而难以把这些数据包还原成完整的文件。

TCP：把数据完整地送达应用程序

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP 有下面两个特点:

• 对于数据包丢失的情况，TCP 提供重传机制；
• TCP 引入了数据包排序机制，用来保证把乱序的数据包组合成一个完整的文件。

TCP是如何保证重传机制和数据包的排序功能的？

TCP连接过程

完整的TCP连接过程，是包括“建立连接”“传输数据”和“断开连接”三个阶段。

• 首先，建立连接阶段。这个阶段是通过“三次握手”来建立客户端和服务器之间的连接。
• 其次，传输数据阶段。在该阶段，接收端需要对每个数据包进行确认操作，也就是接收端在接收到数据包之后，需要发送确认数据包给发送端。所以当发送端发送了一个数据包之后，在规定时间内没有接收到接收端反馈的确认消息，则判断为数据包丢失，并触发发送端的重发机制。同样，一个大的文件在传输过程中会被拆分成很多小的数据包，这些数据包到达接收端后，接收端会按照 TCP 头中的序号为其排序，从而保证组成完整的数据。
• 最后，断开连接阶段。数据传输完毕之后，就要终止连接了，涉及到最后一个阶段“四次挥手”来保证双方都能断开连接。

三次握手

1.客户端发了个连接请求消息到服务端 （设置超时机制）
2.服务端回应客户端请求
3.第三次握手是为了防止已经失效的连接请求报文段突然又传到服务端，因而产生错误。所以，客户端再次往服务器端发送一个请求数据包。

C:I need.
S:I know.
C:Come on!

第三次握手的必要性？

客户端发出去的第一个连接请求由于某些原因在网络节点中滞留了导致延迟，直到连接释放的某个时间点才到达服务端，这是一个早已失效的报文，但是此时服务端仍然认为这是客户端的建立连接请求第一次握手，于是服务端回应了客户端，第二次握手。如果只有两次握手，那么到这里，连接就建立了，但是此时客户端并没有任何数据要发送，而服务端还在傻傻的等候佳音，造成很大的资源浪费。所以需要第三次握手，只要客户端再次回应一下，就可以避免这种情况。

四次挥手

释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。客户端发送确认消息告诉服务器端，避免服务器在超时重传。

多出的一次握手其实就是释放资源。

C:请求断开连接
S:了解，请稍候，这里还有活
S:好了
C:收到.

拓展：浏览器可以同时打开某站点的多个页签，他们端口一样吗？如果一样，数据怎么知道去哪个页签？

HTTP 协议，正是建立在 TCP 连接基础之上的。HTTP 是一种允许浏览器向服务器获取资源的协议，是 Web 的基础。

http:默认80端口 https:默认443 端口。

端口一样的，网络进程知道每个tcp链接所对应的标签是那个，所以接收到数据后，会把数据分发给对应的渲染进程。传递数据包的内容包含网站身份信息，发送到80（http）端口后解读数据包，发现数据包有站点身份信息（比如url），就传递给这个站点。