目录
问题2：为什么建立连接的时候需要三次握手，而释放连接却需要四次挥手？
一、TCP是什么
传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。
二、三次握手建立连接
三次握手通俗可以形容成对话，如下：
男的相当于客户端，女的相当于服务器。当客户端发起连接时，会先发送一个连接请求，当服务端答应(确认)后，客户端再发送一个知道可以说话了的信息给服务端，然后客户端才真正开始说话。
详细的过程如下：
1.一开始，服务器会有个线程时刻监听(listen)是否有客户端的连接请求。
2.客户端主动发送一个连接请求报文段，为了标识这是个连接请求，会把SYN=1，seq=x （seg为报文序号，x是随机产生的）。这个报文段无应用层数据。
3.服务器收到这个请求后，会建立接收缓存区，且回复一个确认连接报文，这个报文同样也会把SYN=1，但是会多了一个确认为ACK，ACK表示收到了前一个报文，并且也会有与ACK成对出现的ack，ack表示渴望收到的下一个报文的报文序号，由于前一个报文序号为x，所以渴望收到的下一个报文序号当然就是x+1了，因此ack=x+1。同样的，这里服务端也会随机出自己的报文号 y 发给客户端。
4。客户端回复一个确认报文段，告知服务器，自己已经知道服务器收到自己的连接请求了。对于客户端而言，发送出去这个报文后，就可以开始建立连接了。而服务器收到这个报文后，才开始建立连接。（SYN只有两个情况会为1，就是连接请求报文和确认收到连接请求报文）
其实三次握手实际就是为了验证客户端和服务端是否都具有发送信息和接收信息的能力：
- 客户端给服务端发送SYN连接请求。服务端收到连接请求后，知道了客户端有发送能力
- 服务端收到连接请求后，回复一个SYN请求给客户端，客户端收到后，知道了服务端有接收能力和发送能力
- 客户端收到服务端发来的SYN请求后，由于要让服务端知道自己有接收能力，因此必须回复一个请求给服务端。
三、四次挥手释放连接
四次挥手通俗可以形容成对话，如下：
当客户端发送完全部数据后，就会告诉服务器自己已经没数据发送了。但是由于TCP是全双工的，即客户端可以给服务器发数据，服务器也可以给客户端发数据，所以虽然客户端自己发送完了，但是还得要等服务器也发送完才能关闭连接。当服务器发送完后，服务器就会告诉客户端自己也没数据可发了，然后客户端收到服务器已发送完数据的消息后，便回了一个确认消息，告诉服务器，客户端已经知道了，服务器可以关闭连接了。
详细如下图：
过程：
1. 客户端发送完所有数据后，向服务器发送一个请求释放连接的报文。此报文FIN为1，这个报文的序号seg=u(这次的u不是随机的，而是等于前面已经传送过来的数据的最后一个字节的序号加1)。
2. 客户端发送完请求释放连接的报文后，就开始等了，分两个阶段等，第一个是 FIN-WAIT-1 ，是等待服务器确认收到客户端发的释放连接的确认报文。
3. 客户端收到服务器发送的确认报文后，就开始等服务器发送完它自己的数据了，这就是第二个阶段的等---FIN-WAIT-2。
4.当服务器把所有数据都发送完毕后，就向客户端发送连接释放报文，只要是连接释放报文，都有FIN=1的。
5.客户端收到后，必须发出确认报文，告诉服务器自己已经知道了，不再等了。
6.服务器收到这个确认报文后，就开始释放连接。
7. 当客户端则会进入 TIME-WAIT，这个等待是怕 自己发送的确认报文在网络中丢失了，如果确认报文丢失了的话，服务器得不到应答，就会重发一次连接释放报文，这时候处于TIME-WAIT的客户端就能够收到，要是客户端没有TIME-WAIT，马上释放连接的话，那么如果确认报文丢失了，客户端就不知道了，这时候服务器会一直重发连接释放报文而不得关闭。
四、TCP的重传机制
主要是两种方式：
1.基于时间的重传
TCP的发送方会设置一个计时器来判断数据传输是否超时。
由于每一个数据包选择的路由(即传输路径)有可能是不一样的，取决于当时的网络情况，因此该如何设定重传时间十分重要，如果重传时间设置太短，就会引起很多报文段不必要的重传，因为有的报文段只是它传输的时间比较长而已，并不是丢失了。但如果设置的太长，又会引起网络空闲时间太多，降低传播效率。
因此，TCP采取了自适应算法来动态地改变重传时间RTTs(加权平均往返时间)
自适应方法步骤：
（1）记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。
（2）TCP保留了RTT的一个加权平均往返时间RTTs（这又成为平滑的往返时间，S表示Smoothed。因为进行的是加权平均，因此获得的结果更加平滑，也就是让我们计算出的结果更加合理）。每回的第一次测量到RTT样本时，RTTs值就取为所测量到的RTT样本值，但以后每次测量到一个新的RTT样本，就按下面的公式重新计算一次RTTs：
在上式中：（阿尔法 的值介于0到1，若很接近0，则表示旧的RTTs值和新的RTTs值相比变化不大，也就是说，新的RTT样本不太影响RTTs; 若很接近1，则表明新的RTTs值，受当前采集的RTT样本影响较大，跟上次的RTTs差距大）
RFC 2988：推荐的阿尔法值为1/8,也就是0.125 （这种方式得出的值更为平滑）
缺点：但是！等的时间有点久！有没有方法可以在超时时间发生之前就可以知道发送方有没有丢失报文段？当然是有的，就是接下来讲的冗余ACK(冗余确认)。
2. 快速重传
冗余ACK(冗余确认)
五、TCP流量控制
流量控制：让发送方发慢点，要让接收方来得及收。
TCP利用滑动窗口机制实现流量控制。
在通信过程中，接收方根据自己接收缓存的大小，动态地调整发送方的发送窗口大小，即接收窗口rwnd（接收方设置确认报文段的窗口字段来将rwnd通知给发送方），发送方的发送窗口 = min(接收窗口rwnd，拥塞窗口cwnd)。发送窗口是可以动态变化的，取决于接收方发送的窗口字段。
例如：A主机向B主机发送数据：
这里有一个问题，上面的例子的最后，rwnd=0，表示主机B暂时不让A发送数据，A必须要等到B发送的rwnd不为0的数据报时才能继续发送数据，但如果B发送的rwnd不为0的数据报在传输中丢失了，传不到给A，那么就会出现死锁，B等待A发送数据，A等到B发送rwnd不为0的数据报。为了解决这个问题：
TCP为每一个连接都设置一个持续计时器，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器到期，就发送一个零窗口的探测报文段。接收方收到探测报文段时会给出现在的窗口值rwnd。若是窗口仍然是0，则发送方重新设置持续计时器。
六、TCP的拥塞控制
出现拥塞的条件：对资源需求的总和>可用资源。
资源：例如网络的一些容量，入带宽，例如一条链路是50兆的带宽，大家都往这条链路发送数据，导致这条链路上的带宽不够大家使用了，就导致了拥塞。
拥塞控制目的：防止过多的数据注入到网络。所以就要协调多台主机使用网络资源。
流量控制是两台主机的问题，拥塞控制是多台主机的问题。
拥塞控制的四种算法：
分别为：慢开始，拥塞避免，快重传，快恢复。其中前两个是组合使用的，后两个也是组合使用的。
基础概念：
发送窗口 = min（接收窗口rwnd，拥塞窗口cwnd）
接收窗口：接收方根据接收缓存设置的值，并告知给发送方，放映的是接收方容量。
拥塞窗口：发送方根据自己估算的网络拥塞程度而设置的窗口值，反应网络当前容量。
（1）慢开始+拥塞避免
一个传输轮次：发送一批报文段并全部收到它们的确认的时间。也可以指为一个传输时延RTT
慢开始：一开始拥塞窗口从小开始增大，因为先要探测一下网络的情况。如果网络状态比较好，就增大拥塞窗口，等于变相增大自己的发送窗口。增大的规律是指数增大，例如一开始的拥塞窗口为1，下一个轮次为2，再下一个轮次为4，然后8，16......
拥塞避免：当拥塞窗口达到了ssthresh阈值，就会把增加策略从指数增长变成加法增长，因为这时候会怕网络开始拥堵了，因此要变慢拥塞窗口的增长策略。当拥塞窗口达到24时，网络拥塞，就马上把拥塞窗口缩小成初始拥塞窗口值(即1)，然后重新开始慢开始过程。
ssthresh的动态改变：只要出现了网络拥塞，马上把当时的拥塞窗口(即24)除以2，定义为新的ssthresh阈值。
（2）快重传+快恢复
快重传：跟之前流量控制一样，由于不用等到重传计时器归零就可以重传数据了，所以有助于提高网络传播效率。
快恢复：当收到3个重复的冗余ACK时(即上图拥塞窗口为24的时候)，就会降到新的ssthresh值处开始拥塞避免。而不是降到1。
常见面试题：
问题1：为什么要三次握手，二次握手行不行？
不行，首先我们来看看第三次握手存在的意义：为了防止已失效的连接报文突然又到了服务器，造成双方的不一致，导致资源兰浪费。
举个例子，如果只有二次握手的话：
1.客户端向服务器发送一个SYN连接请求报文，但是由于网络原因，此报文在传送途中滞留了很长时间。
2.客户端等了很久没等到来自服务器的确认报文，于是客户端以为自己发的SYN连接报文丢包了(其实没有丢)，于是重新发送一个SYN连接报文。
3.这一次服务器收到了，回复了确认报文，双方建立连接。
4.这时候，滞留的SYN报文达到了服务器，如果这个SYN在连接过程中到达，那就没事，因为服务器会自动忽略它。但如果是在释放了连接(即客户端和服务端通信结束后)到达服务器，那么服务器会以为又有客户端想跟它建立连接。
5.那么服务器就会回复一个连接确认报文，因此是二次握手，所以服务器开始建立连接。
6.当客户端收到了这个连接确认报文后，由于客户端此时是没有发起连接请求的，因此客户端会忽略它。
7.这时候，服务器以为连接好了会一直给客户端发送数据，但由于客户端是没处理连接状态的，所以会丢弃服务器发来的数据。
8.过了一会，客户端想向服务器建立连接，发送了新的SYN连接请求报文，但服务器认为已经在连接中了，就不理睬这个新的SYN报文了。就会出现大家都尬在这。服务器发数据，客户端丢弃，客户端想发，服务器又丢弃连接请求。
其实这些问题也不是不能解决的，当客户端老发现服务器给自己发信息，且自己老是丢弃，则可能会向服务器发送一个RST(即报文中RST位置为1)，强制服务器关闭连接。但资源已经被浪费掉了，而三次握手就不会出现这种问题。
问题2：为什么建立连接的时候需要三次握手，而释放连接却需要四次挥手？
先分开来看：
1. 三次握手时：当服务器收到客户端是SYN连接请求时，发送的确认报文中，不仅仅也有ACK确认信息，还有SYN同步信息。所以这是一起发的所以三次握手会比四次挥手少了一次，但为什么在挥手时，不能像握手时这样搞呢？
2. 四次挥手时：服务器收到客户端来的FIN释放连接请求时，服务器不能同时发送ACK和FIN，因为这时候只是客户端发送完数据，但服务器还有数据要发送，所以这时候服务器只能发送 ACK确认已经收到来自客户端的FIN，而要等到服务器发送完全部数据后，服务器才能发送FIN报文。因此，挥手时比握手多出一次的根本原因是，客户端想要释放连接时，服务器还有数据没发完。
问题3：如果在建立连接后，客户端突然出现故障了怎么办？
TCP是有一个保活计时器的，因为如果客户端出故障了，服务器也不能一直等下去，白白耗费资源。服务器每次收到客户端的消息后，都会重新复位这个计时器，时间通常是2小时。若两小时内都没有收到服务器的数据，服务器会发送一个探测报文，以后每隔75秒发送一次，当连续发送10个报文都没有回应时，服务器就认为客户端出了故障，接着就关闭连接。
问题4：什么是SYN洪泛攻击？
由于连接的建立需要三次握手，当攻击方(客户端)给服务器发送一个SYN连接建立报文后，服务器会回复一个ACK确认报文，但攻击方收到服务器的报文后，不给它回复一个再确认的报文，这样子服务器就会以为是自己的确认报文丢失了，然后就会不断重发。这时候，攻击方向服务器发送多个SYN连接请求，但是每个都不建立三次握手，因此在服务器上，这些TCP连接都会消耗CPU和内存，最后服务器死机，无法为正常用户提供服务。
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
