54、浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开？什么情况下会断开？

在 HTTP／1．0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。但是这样每次请求都会重新建立和断开 TCP 连接，代价过大。所以虽然标准中没有设定，某些服务器对 Connection： keep－alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免。

持久连接：既然维持 TCP 连接好处这么多，HTTP／1．1 就把 Connection 头写进标准，并且默认开启持久连接，除非请求中写明 Connection： close，那么浏览器和服务器之间是会维持一段时间的 TCP 连接，不会一个请求结束就断掉。

默认情况下建立 TCP 连接不会断开，只有在请求报头中声明 Connection： close 才会在请求完成后关闭连接。

55、三次握手相关内容

三次握手（Three－way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

第一种回答

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态，进行三次握手：

第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN（c）。此时客户端处于 SYN＿SEND 状态。

首部的同步位SYN＝1，初始序号seq＝x，SYN＝1的报文段不能携带数据，但要消耗掉一个序号。

第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN（s）。同时会把客户端的 ISN ＋ 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN＿RCVD 的状态。

在确认报文段中SYN＝1，ACK＝1，确认号ack＝x＋1，初始序号seq＝y。

第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN ＋ 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

确认报文段ACK＝1，确认号ack＝y＋1，序号seq＝x＋1（初始为seq＝x，第二个报文段所以要＋1），ACK报文段可以携带数据，不携带数据则不消耗序号。

发送第一个SYN的一端将执行主动打开（active open），接收这个SYN并发回下一个SYN的另一端执行被动打开（passive open）。

在socket编程中，客户端执行connect（）时，将触发三次握手。

第二种回答初始状态：客户端处于 closed（关闭）状态，服务器处于 listen（监听） 状态。第一次握手：客户端发送请求报文将 SYN ＝ 1同步序列号和初始化序列号seq ＝ x发送给服务端，发送完之后客户端处于SYN＿Send状态。（验证了客户端的发送能力和服务端的接收能力）第二次握手：服务端受到 SYN 请求报文之后，如果同意连接，会以自己的同步序列号SYN（服务端） ＝ 1、初始化序列号 seq ＝ y和确认序列号（期望下次收到的数据包）ack ＝ x＋ 1 以及确认号ACK ＝ 1报文作为应答，服务器为SYN＿Receive状态。（问题来了，两次握手之后，站在客户端角度上思考：我发送和接收都ok，服务端的发送和接收也都ok。但是站在服务端的角度思考：哎呀，我服务端接收ok，但是我不清楚我的发送ok不ok呀，而且我还不知道你接受能力如何呢？所以老哥，你需要给我三次握手来传个话告诉我一声。你要是不告诉我，万一我认为你跑了，然后我可能出于安全性的考虑继续给你发一次，看看你回不回我。）第三次握手：客户端接收到服务端的 SYN ＋ ACK之后，知道可以下次可以发送了下一序列的数据包了，然后发送同步序列号 ack ＝ y ＋ 1和数据包的序列号 seq ＝ x ＋ 1以及确认号ACK ＝ 1确认包作为应答，客户端转为established状态。（分别站在双方的角度上思考，各自ok）

56、为什么需要三次握手，两次不行吗？

弄清这个问题，我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

57、什么是半连接队列？

服务器第一次收到客户端的 SYN 之后，就会处于 SYN＿RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

这里在补充一点关于SYN－ACK 重传次数的问题：服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s．．．．．．

58、 ISN（Initial Sequence Number）是固定的吗？

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN（Initial Sequence Number），以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

59、 三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据

为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

60、SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS／DDoS 攻击。

检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux／Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

netstat －n －p TCP ｜ grep SYN＿RECV

复制代码

常见的防御 SYN 攻击的方法有如下几种：

缩短超时（SYN Timeout）时间增加最大半连接数过滤网关防护SYN cookies技术

61、 四次挥手相关内容

建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half－close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。

TCP 的连接的拆除需要发送四个包，因此称为四次挥手（Four－way handshake），客户端或服务器均可主动发起挥手动作。

第一种回答

刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN＿WAIT1 状态。即发出连接释放报文段（FIN＝1，序号seq＝u），并停止再发送数据，主动关闭TCP连接，进入FIN＿WAIT1（终止等待1）状态，等待服务端的确认。第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 ＋1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE＿WAIT 状态。即服务端收到连接释放报文段后即发出确认报文段（ACK＝1，确认号ack＝u＋1，序号seq＝v），服务端进入CLOSE＿WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN＿WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST＿ACK 的状态。即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN＝1，ACK＝1，序号seq＝w，确认号ack＝u＋1），服务端进入LAST＿ACK（最后确认）状态，等待客户端的确认。第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 ＋1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME＿WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK＝1，seq＝u＋1，ack＝w＋1），客户端进入TIME＿WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。

收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME＿WAIT是正常的，服务端通常执行被动关闭，不会进入TIME＿WAIT状态。

在socket编程中，任何一方执行close（）操作即可产生挥手操作。

第二种回答初始化状态：客户端和服务端都在连接状态，接下来开始进行四次分手断开连接操作。第一次分手：第一次分手无论是客户端还是服务端都可以发起，因为 TCP 是全双工的。“

假如客户端发送的数据已经发送完毕，发送FIN ＝ 1 告诉服务端，客户端所有数据已经全发完了，服务端你可以关闭接收了，但是如果你们服务端有数据要发给客户端，客户端照样可以接收的。此时客户端处于FIN ＝ 1等待服务端确认释放连接状态。

第二次分手：服务端接收到客户端的释放请求连接之后，知道客户端没有数据要发给自己了，然后服务端发送ACK ＝ 1告诉客户端收到你发给我的信息，此时服务端处于 CLOSE＿WAIT 等待关闭状态。（服务端先回应给客户端一声，我知道了，但服务端的发送数据能力即将等待关闭，于是接下来第三次就来了。）第三次分手：此时服务端向客户端把所有的数据发送完了，然后发送一个FIN ＝ 1，用于告诉客户端，服务端的所有数据发送完毕，客户端你也可以关闭接收数据连接了。此时服务端状态处于LAST＿ACK状态，来等待确认客户端是否收到了自己的请求。（服务端等客户端回复是否收到呢，不收到的话，服务端不知道客户端是不是挂掉了还是咋回事呢，所以服务端不敢关闭自己的接收能力，于是第四次就来了。）第四次分手：此时如果客户端收到了服务端发送完的信息之后，就发送ACK ＝ 1，告诉服务端，客户端已经收到了你的信息。有一个 2 MSL 的延迟等待。

62、挥手为什么需要四次？

第一种回答

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN＋ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，＂你发的FIN报文我收到了＂。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

第二种回答

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

63、2MSL等待状态？

TIME＿WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。

对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME＿WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。

这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。

64、四次挥手释放连接时，等待2MSL的意义？

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST－ACK状态的服务器收不到对FIN－ACK的确认报文。服务器会超时重传这个FIN－ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

两个理由保证客户端发送的最后一个ACK报文段能够到达服务端。这个ACK报文段有可能丢失，使得处于LAST－ACK状态的B收不到对已发送的FIN＋ACK报文段的确认，服务端超时重传FIN＋ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN＋ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME－WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN＋ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。防止“已失效的连接请求报文段”出现在本连接中。客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

65、为什么TIME＿WAIT状态需要经过2MSL才能返回到CLOSE状态？

第一种回答

理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME＿WAIT状态就是用来重发可能丢失的ACK报文。

第二种回答

对应这样一种情况，最后客户端发送的ACK ＝ 1给服务端的过程中丢失了，服务端没收到，服务端怎么认为的？我已经发送完数据了，怎么客户端没回应我？是不是中途丢失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL。

客户端给服务端发送的ACK ＝ 1丢失，服务端等待 1MSL没收到，然后重新发送消息需要1MSL。如果再次接收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL，如果没有再次收到服务端的消息，就说明服务端已经接收到自己确认消息；此时双方都关闭的连接，TCP 四次分手完毕

66、TCP粘包问题是什么？你会如何去解决它？

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。

由TCP连接复用造成的粘包问题。因为TCP默认会使用Nagle算法，此算法会导致粘包问题。只有上一个分组得到确认，才会发送下一个分组；收集多个小分组，在一个确认到来时一起发送。数据包过大造成的粘包问题。流量控制，拥塞控制也可能导致粘包。接收方不及时接收缓冲区的包，造成多个包接收

解决：

Nagle算法问题导致的，需要结合应用场景适当关闭该算法尾部标记序列。通过特殊标识符表示数据包的边界，例如， ，或者一些隐藏字符。头部标记分步接收。在TCP报文的头部加上表示数据长度。应用层发送数据时定长发送。结语

嗯，到这里就结束了。

PDF还没更新哈，还是上次的，下篇更完再出 PDF 版本好了，哈哈。