TCP(Transmission Control Protocol)作为一种传输控制协议，其目标：保证数据安全传输，提高传输的效率（udp是足够快，但是数据不稳定）。
TCP特点：面向连接，占有资源较多的，数据结构复杂（数据无丢失、数据无失序、数据无错误、数据无重复到达）。
面向连接：每个数据报的处理是相互关联的。这也说明， I P数据报按发送顺序接收。
TCP的包头结构：
源端口 16位
目标端口 16位
*** 32位
回应序号 32位
TCP头长度 4位
reserved 6位
控制代码 6位
窗口大小 16位
偏移量 16位
校验和 16位
选项 32位(可选)
这样我们得出了TCP包头的最小长度，为20字节。
UDP的包头结构：
源端口 16位
目的端口 16位
长度 16位
校验和 16位
因此信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。
TCP标志位,有6种标示位:SYN(synchronous建立联机请求) ACK(acknowledgement 确认请求) Sequence number(isn顺序号码) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急) Acknowledge number(确认号码)
TCP标志位和seq ack 序号是不一样的含义。
1.三次握手：
最初两端的TCP进程都处于CLOSED关闭状态，A主动打开连接，而B被动打开连接。
第一次握手：主机A发送同步位SYN=1，初始序号seq=x，主机B由syn=1知道，A要求建立联机 ，进入SYN-SENT状态；
第二次握手：主机B收到请求后要确认联机信息，向A发送SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y，进入SYN-RCVD状态；
第三次握手：主机A会再发送ACK=1，确认号ack=y+1，序号seq=x+1，主机B收到后确认连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
为什么A还要发送一次确认呢？可以二次握手吗？
不可以，二次握手B无法知道A是否已经接收到自己的同步信号，此时A不理睬B的确认且不发送数据，则B一致等待A发送数据，浪费资源。
前俩比较容易理解，第三次握手看似多余其实不然，这主要是为了防止已失效的请求报文段突然又传送到了服务端而产生连接的误判。
比如：客户端发送了一个连接请求报文段A到服务端，但是在某些网络节点上长时间滞留了，而后客户端又超时重发了一个连接请求报文段B该服务端，而后 正常建立连接，数据传输完毕，并释放了连接。但是请求报文段A延迟了一段时间后，又到了服务端，这本是一个早已失效的报文段，但是服务端收到后会误以为客户端又发出了一次连接请求，于是向客户端发出确认报文段，并同意建立连接。那么问题来了，假如这里没有三次握手，这时服务端只要发送了确认，新的 连接就建立了，但由于客户端没有发出建立连接的请求，因此不会理会服务端的确认，也不会向服务端发送数据，而服务端却认为新的连接已经建立了，并在 一直等待客户端发送数据，这样服务端就会一直等待下去，直到超出保活计数器的设定值，而将客户端判定为出了问题，才会关闭这个连接。这样就浪费了很多服务 器的资源。而如果采用三次握手，客户端就不会向服务端发出确认，服务端由于收不到确认，就知道客户端没有要求建立连接，从而不建立该连接。
可以四次握手吗？
最好不要，只需要三次握手，可以提高连接的速度与效率。四次握手效率降低。
Server端易受到SYN攻击？
服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击，SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。
防范SYN攻击措施：降低主机的等待时间使主机尽快的释放半连接的占用，短时间受到某IP的重复SYN则丢弃后续请求。
2、四次挥手：
Client端发起中断连接请求，就是发送FIN报文。Server端接到FIN报文后解析为"我Client端没有数据要发给你了"，但是如果你还有数据没有发送完成，则不能关闭Socket，必须继续发送数据。所以Server先发送ACK，"通知Client端，请求我收到了，但是我还有数据没发送完，没准备好，请等我的消息"。这个时候Client端就进入FIN_WAIT状态，继续等待Server端的FIN报文。当Server端确定数据已发送完成，则向Client端发送FIN报文，"告诉Client端，我这边数据发完了，准备关闭连接了"。Client端收到FIN报文后，"就知道可以关闭连接了，但是他还是不相信网络，怕Server端不知道要关闭，所以发送ACK后进入TIME_WAIT状态，如果Server端没有收到ACK则可以重传。“，Server端收到ACK后，"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！
1）A的应用进程先向其TCP发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
2）B收到连接释放报文段后即发出确认报文段，（ACK=1，确认号ack=u+1，序号seq=v），B进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。
3）A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
4）B没有要向A发出的数据，B发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），B进入LAST-ACK（最后确认）状态，等待A的确认。
5）A收到B的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSED状态。
为什么A在TIME-WAIT状态必须等待2MSL的时间？
MSL最长报文段寿命Maximum Segment Lifetime，MSL=2
保证A发送的最后一个ACK报文段能够到达B。防止“已失效的连接请求报文段”出现在本连接中。
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。