关于TCP的十四个问题

1. TCP是什么？

2. TCP是如何建立（三次握手）？

3. 为什么要三次握手？

4. TCP是如何终止的（四次挥手）？

5. 为什么要四次挥手？

6. 为什么四次挥手中的第四次需要等待2MSL？

7. 一次http请求，谁会先断开TCP连接？什么情况下客户端先断，什么情况下服务端先断？

8. 一个 TCP 连接可以对应几个 HTTP 请求？

9. 一个TCP连接中可以同时发多个HTTP请求吗？

10. 为什么有时候刷新页面不需要重新建立SSL连接？

11. 浏览器对同一Host建立TCP连接的数量有没有限制？

12. 如何区分HTTP/1.X还是HTTP/2.X的请求？

13. 浏览器需要加载有几十张图片的网页时，那么这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？

14. 经典的面试题，URL 在浏览器输入到页面展现的过程中发生了什么？

各位童鞋，继续往下看之前，小二建议先在内心中回答一下这十四道问题，然后带着疑惑，有目的的阅读，效果会更好哟🎨

在搞清TCP是什么之前，我们需先要了解下TCP/IP网路模型。

TCP/IP 是互联网相关的各类协议族的总称，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都属于 TCP/IP 族内的协议。

TCP/IP模型是互联网的基础，它是一系列网络协议的总称。这些协议可以划分为四层，分别为链路层、网络层、传输层和应用层。

图中可以看到TCP与UDP都是属于传输层。

TCP（Transmission Control Protocol，传输控制协议）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。TCP 是面向连接的、可靠的流协议。流就是指不间断的数据结构，你可以把它想象成排水管中的水流。

UDP（User Datagram Protocol，用户数据报协议）是一种无需建立连接就可以发送封装的 IP 数据包的方法。

TCP的面向连接的，虽然说网络的不安全不稳定特性决定了三次握手也不能保证连接的可靠和稳定性，但TCP的三次握手还是在很大程度上保证了连接的可靠性；而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然就不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议，因其不必进行收发数据确认的特点，UDP的开销更小传输速率更高、实时性更好。

TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Seq为X；然后，客户端进入SYN_SEND状态，等待服务器的确认；

第二次握手：服务端收到客户端SYN报文，对SYN报文进行确认，设置ACK为X+1，同时要发送自己的SYN信息，Seq为Y，服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN+ACK报文段，然后将ACK设置为Y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

为了防止因为一些原因造成失效的报文传送到服务器，而导致的问题。

例如在网络情况不佳的情况下，客户端发的连接请求报文在传输中滞留了一段时间才到达服务端，此时当前这个请求报文已失效，但服务端收到这个失效的请求报文后，如果不采用三次握手确认，就会误认为是客户端再次发出的一个新的连接请求，服务端建立连接，然后服务端就一直等待客户端发送数据，但是客户端根本就不知道连接已建立，服务端当然收不到消息，资源被浪费掉。而采用三次握手机制，当失效报文传到服务端时，服务端向客户端发送确认报文段，同意建立连接，这个时候客户端因为没有发起过建立连接的请求，因此不会给服务端回确认消息，服务端收不到确认消息，就知道客户端没有要求建立连接。

当数据传输结束后，就需要断开TCP连接，关于TCP连接断开，这里就提起TCP的四次挥手了。

第一次挥手：主动方（客户端或服务端），设置Seq，向被动方发FIN报文段，主动方进入FIN_WAIT_1状态，主动方说：再见，我要关闭了。

第二次挥手：被动方收到主动方FIN报文段，向主动方回一个ACK报文段，确认序号为Seq+1，主动方进入FIN_WAIT_2状态，被动方说：我知道了。

第三次挥手：被动方向主动方发送FIN报文段，请求关闭连接，同时被动方进入LAST_ACK状态，被动方说：再见，我要关闭了。

第四次挥手：主动方收到被动方的FIN报文段，向被动方发送ACK报文段，然后主动方进入TIME_WAIT状态，被动方收到主动方ACK报文段，就关闭连接，此时主动方等待2MSL后没收到回复后，主动方才关闭连接，主动方说：我知道了，等待2MSL后关闭了连接。

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。主动方第一次挥手即告诉被动方，我没数据需要发送了，被动方收到主动方无数据发送信息之后，这个时候被动方还是可以发送数据给主动方的，被动方进行第二次挥手发送ACK报文给主动方，等待被动方处理完自己的事情，发送FIN报文段时，即第三次挥手，告诉主动方我也没数据需要发送了，这个时候主动方收到FIN报文段就会发送ACK，即第四挥手，告诉被动方你可以关闭了。

MSL(Maximum Segment Lifetime)报文最长存活时间。

原因一：防止旧连接的数据包

当TCP连接关闭之前，有一段报文被网络延迟了，这是有相同端口的新的TCP连接被建立时，延迟的报文抵达了客户端，这个时候客户端是有可能会接收这个过期的报文，这样就会造成数据错乱的问题。

原因二：保证连接正确关闭

当主动方四次挥手的最后一个ACK报文段在网络中丢失了，此时如果主动方不等待2MSL，则直接进入ClOSE状态，那么被动方会一直处于LAST_ACK状态，这时主动方又重新发起TCP连接时，被动方会直接将过程终止，连接无法建立。如果主动方等待2MSL，则会有两个情况，一是被动方收到四次挥手的最后一个ACK报文段，被动方正常关闭连接；二是被动方没有收到四次握手的最后一个ACK报文段时，主动方则会重发FIN关闭连接报文并等待新的ACK报文。

对于http1.0协议来说，如果响应头中有content-length，代表客户端知道body的长度，客户端接收的时候按照这个长度接收，接收完毕后，客户端会主动调用close进入四次挥手。

而对于http1.1协议来说，如果响应头中的Transfer-encoding为chunked传输，则表示body是流式输出，body会被分成多块，且每块会标识长度，或者响应头中有content-length，这两种情况在数据接收完毕后，客户端都会主动调用close进入四次挥手，如果非chunked并没有content-length，则客户端接收数据，直到服务端主动断开连接。

以上两种情况，都是基于没有建立持久连接的情况下，当请求头中connection为keep-alive，服务端在输出完body会开启长连接，如果connection为close，则表示客户端需要关闭长连接，根据协议http1.0默认为close，http1.1默认为keep-alive.

最后在不考虑keep-alive的情况下，http1.0，带content-length，body长度可知，客户端会主动调用close进入四次挥手，不带content-length，body长度不可知，则客户端一直接受数据，直到服务端主动断开。http1.1，带content-length，body长度可知，客户端主动断开；带Transfer-encoding：chunked ，body会被分成多个块，且每块会标识长度，客户端主动断开;不带Transfer-encoding：chunked且不带content-length，则客户端一直接受数据，直到服务端主动断开，

即：如果能够有办法知道服务器传来的长度，都是客户端首先断开；如果不知道就一直接收数据，直到服务端断开。

如果是持久连接的话，一个TCP是可以发送很多个HTTP的请求。

http1.1下开启持久连接，单个TCP连接在同一时刻也只能处理一个请求，one by one 必须要等上一个请求结束才能开始下一个，http1.1为了解决这个问题提出了Pipelining管道化方案，但是这个功能在浏览器中是默认关闭的，其要求收到请求的服务器必须按照请求收到的顺序发送响应，然而客户端无法根据响应结果来判断对应哪个请求。

如果是持久连接的话，是可以复用TCP连接的，刷新页面也不需要重新建立SSL连接。

如果图片都是https连接且在同一域名下，那么浏览器在SSL握手后会和服务器商量能不能用http2，能用就使用Multiplexing多路复用功能在这个连接上进行多路传输，如果用不了，那就看浏览器能在一个host下建立多少个TCP，通过建立多个TCP连接来传输数据，如果大部分连接都被占用，那就只能等待了。

引用文章：

https://juejin.cn/post/6844903490595061767#heading-0

https://www.cnblogs.com/web21/p/6397525.html

https://www.sohu.com/a/451071921_453160

点个在看你最好看