大家好，我是阿秀。
直接进入今天正文，不多逼逼。
上期已经更新了 33 问 33 答，那今天再来更新 33 问 33 答好了哈哈，这是整个系列的第八期了，也是计网系列的第二期，计网还有一期就更新完了。
“
本期内容已同步至 github 仓库，欢迎大家 star。
点击文末左侧的阅读原文即可直达仓库地址，仓库地址：https：／／github．com／forthespada／InterviewGuide
PDF 暂时还没更新过来，等下期第九期，也就是计算机网络最后一期，再出 PDF 好了。
下面是本期 33 问 33 答。
34、DNS查询方式有哪些？递归解析
当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式。局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。
迭代解析
当局部DNS服务器自己不能回答客户机的DNS查询时，也可以通过迭代查询的方式进行解析。局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。
也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。比如说：baidu．com的服务器ip地址在192．168．4．5这里，你自己去查吧，本人比较忙，只能帮你到这里了。
35、HTTP中缓存的私有和共有字段？知道吗？
private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。
Cache－Control： private
public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。
Cache－Control： public
36、GET 方法参数写法是固定的吗？
在约定中，我们的参数是写在 ？ 后面，用 ＆ 分割。
我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。
比如header请求头中添加token，来验证用户是否登录等权限问题。
也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行，万变不离其宗。
37、GET 方法的长度限制是怎么回事？
网络上都会提到浏览器地址栏输入的参数是有限的。
首先说明一点，HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。
浏览器原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。
38、POST 方法比 GET 方法安全？
有人说POST 比 GET 安全，因为数据在地址栏上不可见。
然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。
要想安全传输，就只有加密，也就是 HTTPS。
39、POST 方法会产生两个 TCP 数据包？你了解吗？
有些文章中提到，POST 会将 header 和 body 分开发送，先发送 header，服务端返回 100 状态码再发送 body。
HTTP 协议中没有明确说明 POST 会产生两个 TCP 数据包，而且实际测试（Chrome）发现，header 和 body 不会分开发送。
所以，header 和 body 分开发送是部分浏览器或框架的请求方法，不属于 post 必然行为。
40、Session是什么？
除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。
Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。
41、使用 Session 的过程是怎样的？
过程如下：
用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；服务器返回的响应报文的 Set－Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。
注意：Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。
42、Session和cookie应该如何去选择（适用场景）？
Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密；对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。
43、Cookies和Session区别是什么？
Cookie和Session都是客户端与服务器之间保持状态的解决方案
1，存储的位置不同，cookie：存放在客户端，session：存放在服务端。Session存储的数据比较安全
2，存储的数据类型不同两者都是key－value的结构，但针对value的类型是有差异的cookie：value只能是字符串类型，session：value是Object类型
3，存储的数据大小限制不同cookie：大小受浏览器的限制，很多是是4K的大小， session：理论上受当前内存的限制
4，生命周期的控制cookie的生命周期当浏览器关闭的时候，就消亡了
（1）cookie的生命周期是累计的，从创建时，就开始计时，20分钟后，cookie生命周期结束，
（2）session的生命周期是间隔的，从创建时，开始计时如在20分钟，没有访问session，那么session生命周期被销毁。
44、DDos 攻击了解吗？
客户端向服务端发送请求链接数据包，服务端向客户端发送确认数据包，客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认没有彻底根治的办法，除非不使用TCPDDos 预防：
1）限制同时打开SYN半链接的数目
2）缩短SYN半链接的Time out 时间
3）关闭不必要的服务
45、MTU和MSS分别是什么？
MTU：maximum transmission unit，最大传输单元，由硬件规定，如以太网的MTU为1500字节。
MSS：maximum segment size，最大分节大小，为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header（20 Byte）和TCP header（20 Byte）得到。
46、HTTP中有个缓存机制，但如何保证缓存是最新的呢？（缓存过期机制）
max－age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。
max－age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。
Cache－Control： max－age＝31536000
Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。
Expires： Wed， 04 Jul 2012 08：26：05 GMT
在 HTTP／1．1 中，会优先处理 max－age 指令；在 HTTP／1．0 中，max－age 指令会被忽略掉。
47、TCP头部中有哪些信息？
序号（32bit）：传输方向上字节流的字节编号。初始时序号会被设置一个随机的初始值（ISN），之后每次发送数据时，序号值 ＝ ISN ＋ 数据在整个字节流中的偏移。假设A －＞ B且ISN ＝ 1024，第一段数据512字节已经到 B，则第二段数据发送时序号为1024 ＋ 512，用于解决网络包乱序问题。
确认号（32bit）：接收方对发送方TCP报文段的响应，其值是收到的序号值 ＋ 1。
首部长（4bit）：标识首部有多少个4字节 ＊ 首部长，最大为15，即60字节。
标志位（6bit）：
URG：标志紧急指针是否有效。
ACK：标志确认号是否有效（确认报文段）。用于解决丢包问题。
PSH：提示接收端立即从缓冲读走数据。
RST：表示要求对方重新建立连接（复位报文段）。
SYN：表示请求建立一个连接（连接报文段）。
FIN：表示关闭连接（断开报文段）。
窗口（16bit）：接收窗口。用于告知对方（发送方）本方的缓冲还能接收多少字节数据。用于解决流控。
校验和（16bit）：接收端用CRC检验整个报文段有无损坏。
48、常见TCP的连接状态有哪些？
CLOSED：初始状态。LISTEN：服务器处于监听状态。SYN＿SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。SYN＿RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。ESTABLISH：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。FIN＿WAIT＿1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。CLOSE＿WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。但是本方是否立即断开连接（发送FIN包）取决于是否还有数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。FIN＿WAIT＿2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FIN＿WAIT＿2状态。LAST＿ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。TIME＿WAIT：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIME＿WAIT状态。
49、网络的七层／五层模型主要的协议有哪些？
50、TCP是什么？
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
51、TCP头部报文字段介绍几个？各自的功能？
source port 和 destination port两者分别为「源端口号」和「目的端口号」。源端口号就是指本地端口，目的端口就是远程端口。
可以这么理解，我们有很多软件，每个软件都对应一个端口，假如，你想和我数据交互，咱们得互相知道你我的端口号。
再来一个很官方的：
“扩展：应用程序的端口号和应用程序所在主机的 IP 地址统称为 socket（套接字），IP：端口号， 在互联网上 socket 唯一标识每一个应用程序，源端口＋源IP＋目的端口＋目的IP称为”套接字对“，一对套接字就是一个连接，一个客户端与服务器之间的连接。
Sequence Number称为「序列号」。用于 TCP 通信过程中某一传输方向上字节流的每个字节的编号，为了确保数据通信的有序性，避免网络中乱序的问题。接收端根据这个编号进行确认，保证分割的数据段在原始数据包的位置。初始序列号由自己定，而后绪的序列号由对端的 ACK 决定：SN＿x ＝ ACK＿y （x 的序列号 ＝ y 发给 x 的 ACK）。
说白了，类似于身份证一样，而且还得发送此时此刻的所在的位置，就相当于身份证上的地址一样。
Acknowledge Number称为「确认序列号」。确认序列号是接收确认端所期望收到的下一序列号。确认序号应当是上次已成功收到数据字节序号加1，只有当标志位中的 ACK 标志为 1 时该确认序列号的字段才有效。主要用来解决不丢包的问题。
TCP Flag
TCP 首部中有 6 个标志比特，它们中的多个可同时被设置为 1，主要是用于操控 TCP 的状态机的，依次为URG，ACK，PSH，RST，SYN，FIN。
当然只介绍三个：
ACK：这个标识可以理解为发送端发送数据到接收端，发送的时候 ACK 为 0，标识接收端还未应答，一旦接收端接收数据之后，就将 ACK 置为 1，发送端接收到之后，就知道了接收端已经接收了数据。SYN：表示「同步序列号」，是 TCP 握手的发送的第一个数据包。用来建立 TCP 的连接。SYN 标志位和 ACK 标志位搭配使用，当连接请求的时候，SYN＝1，ACK＝0连接被响应的时候，SYN＝1，ACK＝1；这个标志的数据包经常被用来进行端口扫描。扫描者发送一个只有 SYN 的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口。FIN：表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的 TCP 数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。发送端只剩最后的一段数据了，同时要告诉接收端后边没有数据可以接受了，所以用FIN标识一下，接收端看到这个FIN之后，哦！这是接受的最后的数据，接受完就关闭了；TCP四次分手必然问。
Window size称为滑动窗口大小。所说的滑动窗口，用来进行流量控制。
52、OSI 的七层模型的主要功能？
物理层：利用传输介质为数据链路层提供物理连接，实现比特流的透明传输。数据链路层：接收来自物理层的位流形式的数据，并封装成帧，传送到上一层网络层：将网络地址翻译成对应的物理地址，并通过路由选择算法为分组通过通信子网选择最适当的路径。传输层：在源端与目的端之间提供可靠的透明数据传输会话层：负责在网络中的两节点之间建立、维持和终止通信表示层：处理用户信息的表示问题，数据的编码，压缩和解压缩，数据的加密和解密应用层：为用户的应用进程提供网络通信服务
53、应用层常见协议知道多少？了解几个？
协议名称默认端口底层协议HTTP超文本传输协议80TCPHTTPS超文本传输安全协议443TCPTelnet远程登录服务的标准协议23TCPFTP文件传输协议20传输和21连接TCPTFTP简单文件传输协议21UDPSMTP简单邮件传输协议（发送用）25TCPPOP邮局协议（接收用）110TCPDNS域名解析服务53服务器间进行域传输的时候用TCP
客户端查询DNS服务器时用 UDP
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 版本好了，哈哈。
