TCP三次握手

• Source Port / Destination Port:这个就是客户端口(源端口)和服务器端口（目的端口）. 端口就是用来区别主机中的不同进程，通过结合源IP和目的IP结合，得出唯一的TCP连接。

• Sequence Number(seqNumber): 一般由 客户端发送，用来表示报文段中第一个数据字节在数据流中的序号，主要用来解决网络包乱序的问题。

• Acknowledgment Number(ACK): 即就是用来存放客户端发来的seqNumber的下一个信号(seqNumber+1). 只有当 TCP flags中的ACK为1时才有效. 主要是用来解决不丢包的问题。

• TCP flags: TCP中有6个首部，用来控制TCP连接的状态.取值为0,1.这6个有:URG，ACK，PSH，RST，SYN，FIN.

  • URG 当为1时，用来保证TCP连接不被中断, 并且将该次TCP内容数据的紧急程度提升(就是告诉电脑，你丫赶快把这个给resolve了)

  • ACK 通常是服务器端返回的。 用来表示应答是否有效。 1为有效，0为无效

  • PSH 表示，当数据包得到后，立马给应用程序使用(PUSH到最顶端)

  • RST 用来确保TCP连接的安全。 该flag用来表示 一个连接复位的请求。 如果发生错误连接，则reset一次，重新连。当然也可以用来拒绝非法数据包。

  • SYN 同步的意思,通常是由客户端发送，用来建立连接的。第一次握手时: SYN:1 , ACK:0. 第二次握手时: SYN:1 ACK:1

  • FIN 用来表示是否结束该次TCP连接。 通常当你的数据发送完后，会自动带上FIN 然后断开连接

TCP 3次握手

• 第一次握手. 客户端向服务器发送一个SYN包，并且添加上seqNumber(假设为x),然后进入SYN_SEND状态，并且等待服务器的确认。

• 第二次握手: 服务器接受SYN包，并且进行确认，如果该请求有效，则将TCP flags中的ACK 标志位置1， 然后将AckNumber置为(seqNumber+1)，并且再添加上自己的seqNumber(y), 完成后，返回给客户端.服务器进入SYN_RECV状态.(这里服务端是发送SYN+ACK包)

• 第三次握手 客户端接受ACK+SYN报文后，获取到服务器发送seqNumber(y), 并且 将新头部的AckNumber变为(y+1).然后发送给服务器，完成TCP3次连接。此时服务器和客户端都进入ESTABLISHED状态.

回答一下这个比较尴尬的问题，为什么只有3次握手，而不是4次，或者2次？
很简单呀，因为3次就够了,干嘛用4次。23333. 举个例子吧，假如是2次的话， 可能会出现这样一个情况。

• 当客户端发送一次请求A后，但是A在网络延迟了很久， 接着客户端又发送了一次B，但是此时A已经无效了。 接着服务器相应了B，并返回TCP连接头，建立连接(这里就2次哈)。 然后，A 历经千山万水终于到服务器了， 服务器一看有请求来了，则接受，由于一开始A带着的TCP格式都是正确的，那么服务器，理所应当的也返回成功连接的flag，但是，此时客户端已经判断该次请求无效，废弃了。 然后服务器，就这么一直挂着(浪费资源)，造成的一个问题是，md, 这个锅是谁的？ 所以，为了保险起见，再补充一次连接就可以了。所以3次是最合适的。在Chinese中，以3为起称为多，如果你用4，5，6，7，8...次的话，这不更浪费吗？

三次握手存在的缺陷：会引起SYN Flood

2.1、SYN Flood 攻击

SYN- Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击，它就是利用了TCP协议实现上的一个缺陷，通过向网络服务所在端口发送大量 的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问。这种攻击早在1996年就被发现，但至今仍然显示 出强大的生命力。很多操作系统，甚至防火墙、路由器都无法有效地防御这种攻击，而且由于它可以方便地伪造源地址，追查起来非常困难。它的数据包特征通常 是，源发送了大量的SYN包，并且缺少三次握手的最后一步握手ACK回复。 
原理：攻击者首先伪造地址对 服务器发起SYN请求，服务器回应(SYN+ACK)包，而真实的IP会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务器不知 道(SYN+ACK)是否发送成功，默认情况下会重试5次（tcp_syn_retries）。这样的话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造IP的话，对于服务器就很难根据IP来判断攻击者，给防护带来很大的困难。

2.2、SYN Flood 防护措施

2.2.1． 无效连接监视释放 
这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉，”伤敌一千，自损八百“ 
2.2.2． 延缓TCB分配方法 
SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB资源，从而占用了系统资源，因此有俩种技术来解决这一问题 
Syn Cache技术 
这种技术在收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配TCB 
Syn Cookie技术 
Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方 的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源 
2.2.3． 使用SYN Proxy防火墙 
原理：对试图穿越的SYN请求进行验证之后才放行

TCP4次挥手

• 第一次挥手: A机感觉此时如果keep-alive比较浪费资源，则他提出了分手的请求。设置SeqNumber和AckNumber之后，向B机发送FIN包, 表示我这已经没有数据给你了。然后A机进入FIN_WAIT_1状态

• 第二次挥手:B机收到了A机的FIN包，已经知道了A机没有数据再发送了。此时B机会给A机发送一个ACK包，并且将AckNumber变为 A机传输来的SeqNumber+1. 当A机接受到之后，则变为FIN_WAIT_2状态。表示已经得到B机的许可，可以进行关闭操作。不过此时，B机还是可以向A机发送请求的。

• 第三次挥手 B机向A机发送FIN包，请求关闭，相当于告诉A机，我这里也没有你要的数据了。然后B机进入CLOSE_WAIT状态.（这里还需要带上SeqNumber，大家看图说话就可以了）

• 第四次挥手 A机接收到B机的FIN包之后，然后同样，发送一个ACK包给B机。 B机接受到之后，就断开了。 而A机 会等待2MSL之后，如果没有回复，确保服务器端确实是关闭了。然后A机也可以关闭连接。A,B都进入了CLOSE状态.

常见问题：为什么连接的时候是三次握手，关闭的时候却是四次握手？

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

经历状态：

Client端所经历的状态

Server端所经历的状态

各种状态解析

FIN_WAIT_1: FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是： FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）

FIN_WAIT_2：上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外一方告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）

TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）

CLOSING（比较少见）: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送FIN报文后，按理来说是应该先收到（或同时收到）对方的 ACK报文，再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢？其实细想一下，也不难得出结论：那就是如果双方几乎在同时close一个SOCKET的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态，表示双方都正在关闭SOCKET连接。

CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是查看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）

LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）

CLOSED: 表示连接中断。

问题：为什么存在TIME_WAIT状态？

答：1、可靠的终止TCP连接

如果服务器发送的FIN保温丢失，那么服务器会重发结束报文段，因此客户端需要停留在某个状态以处理重复收到的结束报文段。否则，客户端会以复位报文段回复服务器，服务器会认为这是一个错误，因为它想要收到一个确认报文段。

2.保证让迟来的TCP报文段有足够的时间被识别并丢弃

当连接处于TIME_WAIT状态，无法立即使用该连接占用的接口重新建立连接。假如说不存在TIME_WAIT状态，应用程序可以立即建立一个和刚关闭的连接相似的连接，新连接可能会接收到属于原来连接的报文。