本文已参加「新人创造礼」活动，一同敞开创造之路。
三次握手
三次握手其实是指树立一个TCP衔接时，需求客户端和服务端一共发送三个包
1. 三次握手的首要作用
- 承认客户端和服务端的承受和发送才干是否正常；
- 指定自己的初始化序列号为后边的可靠性传输做准备；
其实便是衔接服务器的指定端口，树立TCP衔接，而且同步两边的序列号和承认号，交换TCP窗口巨细的信息
2. 三次握手的进程
初始==客户端处于Close==状况，==服务端处于Listen状况==，进行三次握手
2.1 第一次握手
客户端向服务端发送一个SYN报文，指明客户端的初始化序列号ISN，宣布该报文后，==客户端处于SYN-SENT==状况（同步位SYN=1；初始序号Seq=x）
2.2 第2次握手
服务端收到客户端的SYN报文后，会以自己的SYN报文作为应对，相同指定了自己的初始化序列号ISN（s），一起将客户端的ISN+1作为ack（承认号）的值，表示自己现已收到了客户端的SYN报文，宣布该报文后，==服务器处于SYN-RCVD状况==（SYN=1；ACK=1；承认号ack=x+1；Seq=y）
2.3 第三次握手
客户端收到服务端的SYN报文后，会发送一个ACK报文，相同会将服务端的ISN+1作为ack的值，表示现已收到了服务端的SYN报文，宣布该报文后，==客户端处于ESTABLISHED状况==，==服务器收到ACk报文后，也处于ESTABLISHED状况==。此刻，两边树立TCP衔接；（承认报文段ACK=1；承认号ack=y+1；序号Seq=x+1）
初始序号是x，此刻是客户端发送给服务端的第二个报文，所以在初始的状况上加1
3. 三次握手的反常处理
3.1 第一次握手丢掉
假定第一次握手丢掉了，客户端迟迟未收到服务端的承认（SYN-ACK）报文，那么就会触发超时重传机制，（一般第一次重传是一秒后，第2次是两秒后，第三次是四秒后…每次超时重传时刻是上次的两倍，超时重传的最大次数一般是五次，当第五次重传后，会继续等候32秒，假定服务端依然没有回复，客户端会断开TCP衔接）==客户端重发SYN报文，直到最大重发次数==；耗时63秒，大约一分钟左右；
3.2 第2次握手丢掉
第2次握手的报文端包括SYN和ACK两个报文段：
- ACk报文段是对第一次握手的承认报文；
- SYN报文是服务端建议树立TCP衔接的报文；
所以当第2次握手报文丢掉，客户端迟迟未收到服务端的承认报文，==客户端会认为是自己的第一次握手（SYN报文）丢掉，触发超时重传机制，所以会重发SYN报文==；其次，由于第2次握手丢掉，服务端就收不到第三次握手，所以==服务端触发超时重传机制，重传SYN-ACK报文==
3.3 第三次握手丢掉
假定第三次握手丢掉了，==服务端迟迟未收到客户端的承认报文，会认为是第2次握手（SYN-ACK）丢掉，触发超时重传机制，重发SYN-ACK报文==，知道收到第三次握手或许抵达最大重传次数；
- ACK报文不会重传
3.4 为什么需求三次握手，两次可以吗？
咱们首要弄明白三次握手的意图是什么，两次可以抵达相同的意图嘛？
① 第一次握手：客户端发送包，服务端收到了； : 所以服务端得出了结论：客户端的发送才干和服务端的接纳才干正常；
② 第2次握手：服务端发包，客户端收到了； : 所以客户端得出结论：客户端的发送、承受才干和服务端的发送承受才干都正常；不过此刻的服务端并不知道客户端的接纳才干是否正常；
③第三次握手：客户端发包，服务端收到了； : 这样服务端才干得出结论：两边的发送和承受才干都是正常的；
假定采用两次握手，那么只需宣布承认报文就能树立TCP衔接，那么有或许呈现以下情况：
客户端宣布了一个SYN报文，向服务端恳求衔接，可是由于某种原因在网络中长时刻的逗留，而客户端认为是丢掉了，再次重传了SYN报文，该报文正常抵达了服务端，服务端回复SYN-ACK报文，，树立衔接，数据传输完毕后，开释掉了衔接，而此刻，第一个SYN报文才姗姗来迟，抵达服务端，服务端认为是客户端建议的新的衔接恳求，回复SYN-ACK报文，树立衔接等候客户端发送数据，可是，客户端会忽略SYN-ACK报文，也不发送数据，而服务端一向等候客户端发送数据，浪费资源！
3.5 半衔接行列
服务端第一次收到客户端的SYN报文，就会处于SYN-RCVD状况，此刻两边还没有完全树立TCP衔接，服务器会将这种状况下的恳求衔接放到一个行列中，称之为半衔接行列， 相应的，完成了三次握手，树立了TCP衔接的就会放在全衔接行列中，行列满了或许会呈现丢包现象.
3.6 ISN是固定的吗？
不是，他是动态生成的。
- 每个衔接都有不同的ISN，ISN可以看做是一个32比特的计数器；
- 这样挑选序号的意图是避免在网络中被推迟的分组在以后又被传送，而导致某个衔接的一方对他做出错误的解说；
- 假定ISN是固定的，进犯者很容易猜出后续的承认号，因而ISN一定是动态生成的，随时刻改变的；
3.7 三次握手的进程中能带着数据吗？
第一次握手和第2次握手不能带着数据，可是第三次可以带着数据；
假定第一次握手可以带着数据，那么有人歹意进犯服务器就可以在第一次握手的SYN报文中假定很多的数据，进犯者不在意服务器的收发才干是否正常，只需发送很多的SYN报文，就会让服务器花费很多的时刻和内存来接纳处理这些报文；
所以，第一次握手不可以带着数据，其中一个简单的原因便是让服务器更容易遭到进犯； 而关于第三握手来说，客户端现已处于ESTABLISHED状况，并知道服务器的收发才干都正常，所以可以带着数据也可以承受；
3.8 SYN进犯
首要咱们要知道一点：==服务端的资源是第2次握手是分配的，而客户端的资源是在完成三次握手时分配的==， 所以服务端就更容易遭到SYN洪泛进犯； SYN洪泛进犯便是客户端在短时刻内假造很多不存在的IP地址，而且向服务器发送SYN包，服务器则回复SYN-ACK，而且等候客户端的承认，由于源地址是假造的，并不存在，因而服务器需求一向重发直到最大重传次数，这些假造的SYN包也将长时刻占据半衔接行列，导致正常的衔接恳求由于半衔接行列满而被丢掉，然后引起网络拥塞甚至体系的瘫痪。 SYN是一种典型的DOS/DDOS进犯
在Linux/unix体系中，可以运用体系自带的netstat指令来检测SYN洪泛进犯；
- natstat -n -p TCP | grep SYN-ACK
常见的防护SYN进犯的方法：
- 缩短超时（SYN Timeout）时刻
- 增加最大半衔接数
- 过滤网关防护
- SYN Cookies技能
四次挥手
树立一个TCP衔接需求三次握手，终止一个衔接需求经过四次挥手，这是由==TCP的半封闭形成的==，所谓的半封闭，即是指TCP供给了衔接的一端在完毕他的发送后还能收到来自另一端数据的才干； TCP衔接的撤除需求客户端和服务端发送四个包，所以称为四次挥手。 客户端或许服务端都可以自动建议挥手动作，一般是客户端自动建议；
4. 四次挥手的进程
初始状况，==两边都处于ESTABLISHED状况==，假定客户端先建议封闭恳求。
4.1 第一次挥手
客户端发送一个FIN报文，，报文中会指定一个序列号，宣布该报文后，==客户端处于FIN-WAIT1状况== 即宣布衔接开释报文段（FIN=1；Seq=u）并中止再发送数据，自动封闭TCP衔接，进入FIN-WAIT1（终止等候1）状况，等候服务端的承认；
4.2 第2次挥手
服务端收到FIN报文之后，会回复ACK报文，且把客户端的序列号加1作为承认号，表明现已收到客户端的报文了，此刻==服务端处于Clase-WAIT2状况==。 即服务端收到衔接开释报文后即宣布承认报文段（ACK=1；承认号ack=u+1；Seq=v）服务端进入Clase-WAIT状况（封闭等候），此刻的TCP衔接处于半封闭状况客户端到服务端的衔接开释，客户端收到服务端的承认后，进入FIN-WAIT2（终止等候2）状况，等候服务端宣布衔接开释报文段；
4.3 第三次挥手
假定服务端也想封闭TCP衔接，和客户端的第一次挥手相同，宣布FIN报文，且指定一个序列号，，此刻==服务端处于LAST-ACK状况==。 即服务器端宣布衔接开释报文段（FIN=1；ACK=1；Seq=w；承认号ack=u+1）服务端进入LAST-ACK（最终承认）状况，等候客户端的承认；
4.4 第四次挥手
客户端收到服务端的衔接开释报文段后，相同宣布一个ACK报文段作为应对，且把服务端的序列号加1作为自己的ACK报文的承认号，，此刻==客户端处于TIME-WAIT状况==，需求等候一段时刻以确保服务端收到自己的ACK报文之后才会进入Close状况，==服务端收到ACK报文段之后就处于封闭衔接（Close）状况==。 即客户端收到服务端的FIN后，对此宣布承认报文段（ACK=1；Seq=u+1；ack=w+1）客户端进入TIME-WAIT（时刻等候）状况，此刻TCP衔接未开释掉，需求经过时刻等候计时器设置的时刻2MSL后，==客户端才进入Close状况==。
5.四次挥手的反常处理
5.1 第一次挥手丢掉
当客户端（自动封闭方）调用close函数后，就会向服务端发送FIN报文，企图与服务端断开衔接； 假定FIN报文丢掉，客户端迟迟未收到服务端的承认报文，就会触发超时重传机制，重传FIN报文，当重发次数超越最大重传次数时，就不在发送FIN报文，而是直接进入close状况；
5.2 第2次挥手丢掉
第2次挥手是服务端发送的ACK报文，丢掉之后，ACK报文是不会重传的；假定丢掉了，客户端会认为是第一次挥手（FIN）丢掉，触发超时重传机制，重传FIN，知道收到服务端的ACK报文或许超越最大重传次数； 当客户端收到第2次挥手后，会进入FIN-WAIT2状况，在此状况下等候服务端发送第三次挥手（FIN）报文，关于close函数封闭的衔接，由于无法再发送和承受数据，所以，FIN-WAIT2状况不可以继续太久，默许是60秒，这就意味着若60秒之后还没有收到FIN报文，客户端的衔接就会直接封闭；
5.3 第三次挥手丢掉
第三次挥手丢掉，服务端迟迟未收到客户端回复的ACk，就会触发超时重传机制，直到收到第四次挥手或许抵达最大重传次数，假定仍旧没有收到ACK，则直接断开衔接；
5.4 第四次挥手丢掉
当客户端收到服务端的第三次挥手后，就会回复ACK报文，也便是第四次挥手，一起进入TIME-WAIT状况，在Linux体系中，TIME-WAIT状况会继续60秒后才会进入封闭状况；服务端在没有收到ACK报文之前还是处于LAST-ACK状况，假定第四次挥手丢掉，服务端就会重发FIN报文;
5.5 挥手为什么需求四次？
当服务端收到客户端的的SYN衔接恳求报文后，可以直接发送SYN+ACK报文，Ack报文是用来应对的，SYN报文是用来同步的，可是封闭衔接时，当服务端收到FIN报文时，很或许并不会封闭Socket，所以只能先回复ACK报文，告诉客户端FIN收到了，只要等到服务端所有报文都发送完了，才干发送FIN报文；
5.6 2MSL等候状况
TIME-WAIT状况也称为2MSL等候状况，每个具有TCP完成必须挑选一个报文最大生计时刻MSL（maximun segment lifetime）它是任何报文段被丢掉在网络内的最长时刻，由于TCP报文段以IP数据报在网络中传输，而IP数据报则有限制其生计时刻的TTL字段； 对一个具体完成所给定的MSL值，处理的原则是：当TCP履行一个自动封闭，并发回最终一个ACK，该衔接必须在TIME-WAIT状况逗留的时刻为2倍的MSL，这样可以让TCP再次发送最终的ACK，以避免这个ACK丢掉（另一端超时并重发最终的FIN） 在等候时刻内，定义该衔接的插口（客户端和服务端的IP地址和端口号）不能被运用，只要等候2MSL后才干再次被运用；
5.7 等候2MSL的意义
为了保证客户端发送的最终一个ACK报文可以抵达服务端，由于该ACK报文有或许丢掉，然后导致处在LSAT-ACK状况的服务端收不到对FIN的承认报文，服务端会超时重传FIN报文，客户端再重传一次承认，而且重置等候计时器，假定客户端不等候2MSL，而是在发送完ACK后直接封闭，一旦这个ACK丢掉，服务器就无法正常封闭衔接； 所以，有两个意图：
- 保证客户端发送的ACK报文段可以抵达服务端
- 避免“已失效的衔接恳求报文段”呈现在新的衔接中 →客户端在发送完最终一个ACK报文段后，再等候2MSL，就可以使本衔接继续时刻内所发生的所有报文段都从网络中消失，使下一个新的衔接中不会呈现旧的恳求报文段；
