三次握手过程

1）如何理解连接

对于服务器来说，服务器是1对多的，一个服务器可能要被很多个客户端连接。因此，服务器端需要将众多的连接进行管理，这就导致服务器得为这些连接建立相应的数据结构，同时这些操作也是需要时间的。所以，建立连接是需要时间+空间代价的。

2）三次握手过程

• 一般情况下，第一次连接请求是由客户端主动发送的。
• 客户端向服务器发送一个SYN请求，并将自己置为SYN_SENT状态，阻塞等待服务器的应答。
• 服务器收到客户端的请求后，会向服务器端发送一个SYN+ACK数据包。表示服务器端收到客户端的请求，并且向客户端也发起连接请求。此时，服务器端变为SYN_RCVD，等待客户端的确认。
• 客户端收到服务器端的SYN+ACK数据包后会再次向服务器端发送一个ACK确认数据包，发送成功后客户端置为ESTABLISHED状态，并且认为已经连接成功。
• 当服务器端收到客户端的ACK确认后，此时双方建立连接成功，服务器置为ESTABLISHED状态。

3）为什么是三次握手？

1. 如果是1次握手，客户端给服务器端发送一个连接请求直接就连接成功了，这与udp无连接有什么区别？建立连接是为了更好的管理，一次握手建立连接很容易遭到黑客的SYN洪水攻击，导致服务器宕机。
2. 如果是2次握手，客户端向服务器端发送一个请求，服务器端向客户端发送一个确认，到此请求建立成功。那么存在一个问题，服务器端发送的ACK确认如果丢失了，此时服务器认为已经建立连接成功了，而客户端没有收到服务器的ACK确认认为没有建立连接成功，就会进行超时重传，这样就可能导致服务器端资源浪费，同时2次握手也容易遭到SYN洪水攻击。
3. tcp传输数据时，最新的数据永远是无法保证可靠性的（最新的数据不会进行确认），当进行三次握手时，只要前两次失败客户端和服务器端就会认为连接没有建立成功。但是，如果第3三次握手失败，此时客户端认为建立成功了而服务器端认为没有建立成功，不会为其创建相应的数据结构，并且服务器端没有收到客户端的ACK确认就会进行超时重传，当重传次数达到一定程度后就直接强制断开连接，因此也不会对客户端造成很大的影响。但是，如果是四次连接就会导致服务器端认为连接建立成功，而客户端认为没有建立成功，此时浪费的是服务器资源，服务器是1对多的，如果大量的客户端对服务器连接都出现这种问题，就会给服务器带来巨大的资源浪费，甚至导致服务器崩溃。当然，五次握手和三次握手结果是相同的，但是三次握手是最小保证可靠连接的次数，相比于5/7...节省时间。
4. 总结：为什么三次握手可以，第一个原因就是让服务器不要出现建立误判情况，浪费服务器资源；其次还有一个重要原因就是，以最小成本验证全双工（tcp是全双工的，三次握手就可以保证全双工通信信道的场通）。

四次挥手过程

1）为什么是四次挥手

断开连接是需要上双方同时建立起断开连接状态的，因此需要互相请求和确认，一共就是四次挥手。

2）四次挥手的过程

• 客户端向服务器端发送FIN断开连接请求，发送成功后客户端置为FIN_WAIT1状态。
• 服务器端收到客户端的FIN请求后，需要向客户端发送一个ACK确认。发送成功后，服务器端置为CLOS_WAIT状态。
• 客户端收到服务器端的ACK确认后进入FIN_WAIT2状态。
• 服务器端给客户端发送FIN断开连接请求，并进入ALST_ACK状态。
• 客户端向服务器端发送ACK确认，进入TIME_WAIT状态，此时客户端并没有立刻断开连接。
• 服务器端收到客户端的ACK确认后关闭连接，此时服务器端进入CLOSED状态，断开连接成功。

理解TIME_WAIT和CLOSE_WAIT状态

1）TIME_WAIT状态

为什么客户端给服务器端发完ACK确认后，没有立刻进入CLOSED状态？

对于客户端的最后一次ACK确认，服务器端不会在进行确认，如果客户端立刻进入CLOSED状态，有可能导致服务器端并没有接收到ACK确认，对FIN进行超时重传，但是此时客户端已经断开连接，服务器端是一直收不到客户端确认的，只能等到重传次数到达一定程度强制断开连接。因此，在客户端发送完确认后会等待一段时间，如果在该时间内没有收到服务器端重传的FIN数据就会断开连接，否则对重传的FIN重新进行确认，确保服务器端收到并断开连接。

其次，客户端发送完ACK确认进入TIME_WAIT状态，还有一个重要作用就是防止网络中没有传完，保证历史数据在网络中消散。

2）如何验证TIME_WAIT状态？

setsockopt接口，即使㝉端口处于监听状态也可以进行绑定。

3）CLOSED_WAIT状态

首先屏蔽服务器端程序中关闭文件描述符的代码，启动服务器，让客户端进行链接，客户端连接成功后关掉客户端，此时客户端就向服务器端发送了断开连接的请求，但是由于服务器端屏蔽了close，无法断开连接。此时，查看服务器状态就为CLOSE_WAIT状态。

4）time_wait时间是多少比较合适呢？

2*MSL,msl表示数据从一端发送到另一端需要的最大时间，2MSL就是往返的最大时间。

• 在上面这个图中，整个区域表示的是发送缓冲区。白色区域是滑动窗口
• 滑动窗口中的数据是已经发送等待确认的数据。
• 滑动窗口之前的数据是已经发送并且已经收到确认的数据。
• 滑动窗口之后部分的数据是还没有发送的数据
• 当接收到一个ACK时，滑动窗口的左边会右移。
• 当接收缓冲区（16位窗口大小）变大时，滑动窗口右边右移。因此，当滑动窗口越大时，表示对方的接收能变强。
• 滑动窗口大小除了受对方接收缓冲区剩余大小的影响，还跟拥塞控制有关（后边详细讲解）。因此，滑动窗口越大还表明网络状况好，网络吞吐率高。

新的技术的引入，必然会带来一些新的问题和挑战，滑动窗口虽然解决了数据传输效率低问题，那么如果数据丢包又该如何重传呢？

• 接收端收到了数据，但是接收端发送的ACK丢了。

其实，滑动窗口机制已经很好的解决了这个问题，滑动窗口中是可以容忍部分ACK丢包的，只要后续ACK进行确认即可（ACK确认序号表示的是该序号之前的所有数据都已经收到，接下来向收到的数据的序号）。例如，上图中1001的ACK丢了并不影响，只要后边任意一个到达都表示1~1000的收据已经收到。

• 数据报丢了，接收端，没有收到。

当数据包真正丢失了，是需要进行重传的，这也就要求滑动窗口中发送的ACK要确保他之前的数据都已经接收到。例如，接收端接收到的数据的顺序是1~1000、5001~6000、4001~5000，当接收到5001~6000的数据后不能立即发送6001的ACK，必须等到6001之前的数据全部到达才能发送。

其次，滑动窗口的重传机制和之前的超时重传机制也有所不同。滑动窗口中，如果某一个数据真的丢了（超过时间没有收到），接收方会给发送方发送的每一个不是丢失的数据发送的确认号都是丢失数据的确认号。当接收端接收到三次这个ACK时，会重新对这个ACK的数据进行重新发送。这种机制叫做高速重发机制，也称快重传。

例如：

• 当某一段报文段丢失之后 , 发送端会一直收到 1001 这样的 ACK, 就像是在提醒发送端 " 我想要的是 1001" 一样
• 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答 , 就会将对应的数据 1001 - 2000 重新发送

• 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段, 通过ACK端通知发送端;
• 窗口大小字段越大, 说明网络的吞吐量越高;
• 接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
• 发送端接受到这个窗口之后, 就会减慢自己的发送速度;
• 如果接收端缓冲区满了, 就会将窗口置为0; 这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 使接收端把窗口大小告诉发送端.

注意：实际上接收端和发送端第一次“协商”窗口大小是在三次握手过程中。三次握手建立连接时，SYN包中就包含了窗口大小。

为了解决这个问题，引入了拥塞窗口的概念。开始发送数据的时候，拥塞窗口定义为1，每收到一个ACK拥塞窗口+1，每次发送数据的时候将拥塞窗口和主机端反馈的窗口大小做比较，取最小的作为实际发送的窗口大小。

但是，这样的拥塞窗口增长速度是指数级别的。慢启动只是启动时速度慢，但是增长速度非常快。为了不增长的那么快, 因此不能使拥塞窗口单纯的加倍. 此处引入一个叫做慢启动的阈值。当拥塞窗口超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长。

• 当TCP开始启动的时候, 慢启动阈值等于窗口最大值;
• 在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1;

9、延迟应答

如果接收端接收到数据就立即发送ACK确认，这时返回的窗口可能比较小，网络的吞吐率就低，传输效率也就降低了，同时有可能很快缓冲区的数据就会被取走，缓冲区变大。因此，接收端可以延迟一段时间在进行应答，从而提高网络吞吐率。

注意：窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率;同时，延迟应答也不是每一个包都会延迟应答，会有数量（每隔几个包延迟应答一次）和时间（每隔多长时间延迟应答一次）限制。

10、捎带应答

在延迟应答的基础上，其实很多客户端、服务器都是“一发一收”的。捎带应答的意思就是说，接收端收到堆放的数据时，需要进行确认，同时接收端可能也有数据要交给对方，这时就可以将发送的数据和确认信息一起发送给对方。

10、tcp黏包问题

黏包问题是指，应用层发送一个数据包，传输层如果使用的是udp传输，那么该数据包会被分成一个个的报文进行发送，并且每个报文都有数据报长度这样一个字段来区分各个数据报。但是，如果传输层使用的是tcp,tcp传输的是字节流，在应用层看来其实就是一串字符，并且tcp协议中没有报文长度这样的标识，无法知道该报文的有效载荷长度，那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.

那么如何避免呢？对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可; 对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置; 对于变长的包, 还可以在包和包之间使用明确的分隔符。

思考：udp是否会存在这个问题呢？

不会。首先，udp中有udp数据报长度字段可以区分数据报和数据报之间的边界问题。同时，udp是面向数据报的，也就是说一次要么发送一个完整的数据报，要么就不发。

11、tcp异常情况

• 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
• 机器重启: 和进程终止的情况相同（在重启前，电脑会提示还有正在运行的进程是否确认关闭，也就是说重启前会先关闭进程）.
• 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放. 另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ 断线之后, 也会定期尝试重新连接.

1、再次理解什么是面向字节流

创建一个tcp套接字时，系统会为其创建相应的发送缓冲区和接收缓冲区。发送数据时，会先将应用层的用户数据保存在发送缓冲区中，如果缓冲区中的数据太少可以等一段时间在进行发送。如果发送的数据太多了，会被拆分成多个数据包发送出去。另一方面，tcp是全双工的，同一时间同一连接可以同时进行发送和接收数据。由于缓冲区的存在，tcp在发送数据时不必一次性将数据发完，例如：有1000个字节的数据，如果条件允许tcp可以一次发送完，也可以一次发送10个字节，发送100次。

2、基于TCP的应用层协议

• HTTP
• HTTPS
• SSH
• Telnet
• FTP
• SMTP

3、如何使用UDP实现可靠传输

udp是无连接、面向数据报、不可靠传输。要使用udp实现可靠传输就必须在它的上层（应用层）添加可靠性机制，例如：通过确认应答、超时重传、连接管理、流量控制、拥塞控制确保数据的可靠性，其次还可以通过滑动窗口、快速重传、延迟应答、捎带应答等机制提高效率。

4、理解Listen的第二个参数

• 半链接队列：用来保存处于SYN_SENT和SYN_RECV状态的请求（当全连接队列也满了是，如果在有用户连接就会加入到半连接队列中，半连接队列中允许有离开的连接）
• 全连接队列（accpetd队列）：用来保存处于established状态，但是应用层没有调用accept取走的请求（当服务器负载过大时，如果还有客户端连接服务器就可以将它们暂时加入到全连接队列中，当服务器负载减小时在从全连接队列中取走）

5、分析TCP通信流程

在tcp的四次挥手过程中，由于捎带应答的存在，可能导致四次挥手变成三次挥手。也就是说，将第2/3次挥手同时发送过去。

6、TCP小节

实际上tcp在保证数据传输的可靠性的同时，还考虑了很多的效率问题：

可靠性：

• 检验和：检验数据在发送前后是否有改变。
• 序号和确认号：序号保证数据有序到达，确认序号保证对方收到了数据。
• 确认应答：对方在收到数据后会发送一个确认信息，表示自己收到了该数据。
• 超时重传：对丢失的数据或者是没有按时到达的数据重新发送。
• 连接管理：三次握手四次挥手
• 流量控制：根据对方的接收能力和网络状况，控制数据的发送。
• 拥塞控制：解决网络拥堵