前言：该篇说明：请见 说明 —— 浏览器工作原理与实践 目录
在衡量 Web 页面性能的时候有一个重要的指标叫 “FP（First Paint）”，是 指从页面加载到首次开始绘制的时长。这个指标直接影响了用户的跳出率，更快的页面响应意味着更多的PV、更高的参与度，以及更高的转化率。那什么影响 FP 指标呢？其中一个重要的因素是 网络加载速度。
要想优化 Web 页面的加载速度，你需要对网络有充分的了解。而理解网络的关键是要对网络协议有深刻的认识，不管你是使用 HTTP，还是使用 WebSocket，它们都是基于 TCP/IP 的，如果你对这些原理有足够了解，也就清楚如何去优化 Web 性能，或者能更轻松地定位 Web 问题了。此外，TCP/IP 的设计思想还有助于拓宽你的知识边界，从而在整体上提升你对项目的理解和解决问题的能力。
在这篇文章中，我会给你 重点介绍 在 Web 世界中的 TCP/IP 是如何工作的。当然，协议并不是本专栏的重点，这篇文章我会从我的角度结合 HTTP 来分析网络请求的核心路径，如果你想对网络协议有更深入的理解，那我推荐你学习刘超老师的《趣谈网络协议》专栏，以及陶辉老师的《Web 协议详解与抓包实战》视频课程。
接下来回到正题，开始今天的内容。在网络中，一个文件通常会被拆分为很多数据包来进行传输，而数据包在传输过程中又有很大概率丢失或者出错。那么 如何保证页面文件能被完整地送达浏览器呢？
这篇文章将站在数据包的视角，给出问题答案。
一个数据包的“旅程”
下面我将分别从 “数据包如何送达主机” “主机如何将数据包转交给应用” 和 “数据是如何被完整地送达应用程序” 这三个角度来为你讲述数据的传输过程。
互联网，实际上是一套 理念 和 协议 组成的体系架构。其中，协议是一套众所周知的规则和标准，如果各方都同意使用，那么它们之间的通信将变得毫无障碍。
互联网中的数据是通过数据包来传输的。如果发送的数据很大，那么该数据就会被拆分为很多小数据包来传输。比如你现在听的音频数据，是拆分成一个个小的数据包来传输的，并不是一个大的文件一次传输过来的。
1. IP：把数据包传送目的主机
数据包要在互联网上进行传输，就要符合网际协议（Internet Protocol，简称IP）标准。
互联网上不同的在线设备都有唯一的地址，地址只是一个数字，这和大部分家庭收件地址类似，你只需要知道一个家庭的具体地址，就可以往这个地址发送包裹，这样物流系统就能把物品送到目的地。
计算机的地址就称为 IP 地址，访问任何网站实际上只是你的计算机向另外一台计算机请求信息。
如果要想把一个数据包从主机 A 发送给主机 B， 那么在传输之前，数据包上会被附加上主机 B 的 IP 地址信息，这样在传输过程中才能正确寻址。额外地，数据包上还会附加上主机 A 本身的IP 地址，有了这些信息主机 B 才可以回复信息给主机 A。这些附加的信息会被装进一个叫 IP 头的数据结构里。IP 头是 IP 数据包开头的信息，包含 IP 版本、源 IP 地址、目标 IP 地址、生存时间等信息。
为了方便理解，我把网络简单分为三层结构，如下图：
简化的 IP 网络三层传输模型
下面我们一起来看下一个数据包从主机 A 到主机 B 的旅程：
- 上层将含有 “极客时间” 的数据包交给网络层；
- 网络层再将 IP 头附加到数据包上，组成新的 IP 数据包，并交给底层；
- 底层通过物理网络将数据包传输给主机 B；
- 数据包被传输到主机 B 的网络层，在这里主机 B 拆开数据包的 IP 头信息，并将拆开来的数据部分交给上层；
- 最终，含有 “极客时间” 信息的数据包就到达了主机 B 的上层了。
2. UDP：把数据包送达应用程序
IP 是非常底层的协议，只负责把数据包传送到对方电脑，但是对方电脑并不知道把数据包交给哪个程序，是交给浏览器还是交给王者荣耀？因此，需要基于 IP 之上开发能和应用打交道的协议，最常见的是 “用户数据包协议（User Datagram Protocol，简称UDP）”。
UDP 中一个最重要的信息是端口号，端口号其实就是一个数字，每个想访问网络的程序都需要绑定一个端口号。通过端口号 UDP 就能把指定的数据包发送给指定的程序了，所以 IP 通过 IP 地址信息把数据包发送给指定的电脑，而 UDP 通过端口号把数据包分发给正确的程序。和 IP 头一样，端口号会被装进 UDP 头里面，UDP 头再和原始数据包合并组成新的 UDP 数据包。UDP 头中除了目的端口，还有源端口号等信息。
为了支持 UDP 协议，我把前面的三层结构扩充为四层结构，在网络层和上层之间增加了传输层，如下图所示：
简化的 UDP 网络四层传输模型
下面我们一起来看下一个数据包从主机 A 旅行到主机 B 的路线：
- 上层将含有 “极客时间” 的数据包交给传输层；
- 传输层会在数据包前面附加上 UDP 头，组成新的 UDP 数据包，再将新的 UDP 数据包交给网络层；
- 网络层再将 IP 头 附加到数据包上，组成新的 IP 数据包，并交给底层；
- 数据包被传输到主机 B 的网络层，在这里主机 B 拆开 IP 头信息，并将拆开来的数据部分交给传输层；
- 在传输层，数据包中的 UDP 头会被拆开，并根据 UDP 中所提供的端口号，把数据部分交给上层的应用程序；
- 最终，含有 “极客时间” 信息的数据包就旅行到了主机 B 上层应用程序这里。
在使用 UDP 发送数据时，有各种因素会导致数据包出错，虽然 UDP 可以校验数据是否正确，但是对于错误的数据包，UDP 并不提供重发机制，只是丢弃当前的包，而且 UDP 在发送之后也无法知道是否能达到目的地。
虽说 UDP 不能保证数据可靠性，但是传输速度却非常快，所以 UDP 会应用在一些关注速度、但不那么严格要求数据完整性的领域，如在线视频、互动游戏等。
3. TCP：把数据完整地送达应用程序
对于浏览器请求，或者邮箱这类要求数据传输可靠性（reliability）的应用，如果使用 UDP 来传输会存在两个问题：
- 数据包在传输过程中容易丢失；
- 大文件会被拆分成很多小的数据包来传输，这些小的数据包会经过不同的路由，并在不同的时间到达接收端，而 UDP 协议并不知道如何组装这些数据包，从而把这些数据包还原成完整的文件。
基于这两个问题，我们引入了 TCP 了。TPC（Transmission Control Protocol， 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。相对于 UDP， TCP 有下面两个特点：
- 对于数据包丢失的情况，TCP 提供重传机制；
- TCP 引入了数据包排序机制，用来保证把乱序的数据包组合成一个完整的文件。
和 UDP 头一样， TCP 头除了包含了目标端口和本机端口号外，还提供了用于排序的序列号，以便接收端通过序号来重排数据包。
下面看看 TCP 下的单个数据包的传输流程：
简化的 TCP 网络四层传输模型
通过上图你应该可以了解一个数据包是如何通过 TCP 来传输的。TCP 单个数据包的传输流程和 UDP 流程差不多，不同的地方在于，通过 TCP 头的信息保证了一块大的数据传输的完整性。
下面我们再看下 完整的 TCP 连接过程，通过这个过程你可以明白 TCP 是如何保证重传机制和数据包的排序功能的。
从下图可以看出，一个完整的 TCP 连接的生命周期包括了 “建立连接” "传输数据" 和 “断开连接” 三个阶段。
一个 TCP 连接的生命周期
- 首先，建立连接阶段。 这个阶段是通过 “三次握手” 来建立客户端和服务器之间的连接。TCP提供面向连接的通信传输。面向连接是指在数据通信开始之前先做好两端之间的准备工作。所谓三次握手，是指在建立一个 TCP 连接时，客户端和服务器总共要发送三个数据包以确认连接的建立。
- 其次，传输数据阶段。在该阶段，接收端需要对每个数据包进行确认操作，也就是接收端在接收到数据包之后，需要发送确认数据包给发送端。所以当发送端发送一个数据包之后，在规定时间内没有接收到接收端反馈的确认信息，则判断为数据包丢失，并触发发送端的重发机制。同样，一个大的文件在传输过程中会被拆分成很多小的数据包，这些数据包到达接收端后，接收端会按照 TCP 头中的序号为其排序，从而保证组成完整的数据。
- 最后，断开连接阶段。数据传输完毕之后，就要终止连接了，涉及到最后一个阶段 “四次挥手” 来保证双方都能断开连接。
到这里你应该就明白了，TCP 为了保证数据传输的可靠性，牺牲了数据包的传输速度，因为 “三次握手” 和 “数据包校验机制” 等把传输过程中的数据包的数量提高了一倍。
总结
好了，接下来做个简单的总结。
- 互联网中的数据是通过数据包来传输的，数据包在传输过程中容易丢失或出错。
- IP 负责把数据包送达目的主机。
- UDP 负责把数据包送达具体应用。
- 而 TCP 保证了数据完整的传输，它的连接可分为三个阶段：建立连接、传输数据 和 断开连接。
其实了解 TCP 协议，是为了全方位了解 HTTP， 包括其实际功能和局限性，之后才会更加深刻地理解为什么要推出 HTTP/2，以及为什么要推出 QUIC 协议，也就是未来的 HTTP/3 。 这是一个由浅入深、循序渐进的过程，我希望你能稳扎稳打，学好这每一步、每一个协议，后面 “水到自然渠成”。
思考时间
今天这篇文章我没有讲 HTTP 协议，但是相信你应该听说过，HTTP 协议是基于 TCP 协议的，那么今天留给你的问题是：你怎么理解 HTTP 和 TCP 的关系？
HTTP协议和TCP协议都是TCP/IP协议簇的子集。
HTTP协议属于应用层，TCP协议属于传输层，HTTP协议位于TCP协议的上层。
请求方要发送的数据包，在应用层加上HTTP头以后会交给传输层的TCP协议处理，应答方接收到的数据包，在传输层拆掉TCP头以后交给应用层的HTTP协议处理。
建立 TCP 连接后会顺序收发数据，请求方和应答方都必须依据 HTTP 规范构建和解析HTTP报文。
问题
1、现在的浏览器可以同时打开多个页签，他们端口一样吗？如果一样，数据怎么知道去哪个页签？
作者回复: 端口一样的，网络进程知道每个tcp链接所对应的标签是那个，所以接收到数据后，会把数据分发给对应的渲染进程
2、http 和 websocket都是属于应用层的协议吗？
作者回复: 是的，他们都是应用层协议，而且websocket名字取的比较有迷惑性，其实和socket完全不一样，你可以把websocket看出是http的改造版本，增加了服务器向客户端主动发送消息的能力。
3、tcp传送数据时 浏览器端就做渲染处理了么？如果前面数据包丢了 后面数据包先来是要等么？类似的那种实时渲染怎么处理？针对数据包的顺序性？
作者回复: 接收到http响应头中的content-type类型时就开始准备渲染进程了，
响应体数据一旦接受到便开始做DOM解析了！
基于http不用担心数据包丢失的问题，因为丢包和重传都是在tcp层解决的。http能保证数据按照顺序接收的！
4、我想问下，输入url回车后理论上是不是生成http请求报文，然后传给TCP，加上TCP首部，然后进行三次握手，将http请求报文数据传递，四次挥手，请求报文到达服务端，然后服务端在返回响应报文，返回到过程也是要三次握手，传递数据，四次挥手？因为网上看到不少文章都说先三次握手，然后发起http请求。
作者回复:
先通过三次握手建立tcp链接，链接建立好之后，发送http请求行和http请求头给服务器，然后服务器返回响应行，响应头和响应体，
最终完成后通过四次挥手断开tcp链接！
5、想问一下老师，关于 "数据在传输的过程中有可能会丢失或者出错"，丢失的数据包去哪里了？凭空消失了吗？出错的数据包又变成啥了？ 为什么会出错？
作者回复: 比如网络波动，物理线路故障，设备故障，恶意程序拦截，网络阻塞等等
6、老师，那我打开谷歌浏览器里面开了10个页面，那就是至少有40个进程？windows下我控制面板里能看到40个google.exe？插件进程页面间能公用么
作者回复: 不用这么多啊，浏览器进程 网络进程，GPU进程都是共同的，你打开十个页面一般也就十几个进程。