三次握手和四次挥手

网络层，可以实现两个主机之间的通信。其实质，即真正进行通信的实体是在主机的进程中，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。
UDP，在传送数据前不需要先建立连接，远地的主机在收到UDP报文后也不需要给出任何确认。虽然UDP不提供可靠交付，但是正是因为这样，省去和很多的开销，使得它的速度比较快，比如一些对实时性要求较高的服务，就常常使用的是UDP。对应的应用层的协议主要有 DNS,TFTP,DHCP,SNMP,NFS 等。
TCP，提供面向连接的服务，在传送数据之前必须先建立连接，数据传送完成后要释放连接。因此TCP是一种可靠的的运输服务，但是正因为这样，不可避免的增加了许多的开销，比如确认，流量控制等。对应的应用层的协议主要有 SMTP,TELNET,HTTP,FTP 等。
常用的熟知端口号

TCP协议和UDP协议的区别是什么？
①　TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的
②　TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。
③　TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。
④　TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率
⑤　TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。
⑥　TCP面向的是字节流的服务，UDP面向的是报文的服务。
TCP的概述
TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种断点我们叫作套接字（socket），它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16 而端口号为80，那么得到的套接字为192.3.4.16:80。

TCP协议建立连接和终止连接的过程。即三次握手四次挥手的过程。

三次握手

所谓三次握手(Three-way Handshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。
三次握手的目的是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息.在socket编程中，客户端执行connect()时。将触发三次握手。
第一次握手:
建立连接时，客户端A发送SYN包(SYN=j)到服务器B，并进入SYN_SEND状态，等待服务器B确认。客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号(Sequence Number)字段里。

第二次握手:
服务器B收到SYN包，必须确认客户A的SYN(ACK=j+1)，同时自己也发送一个SYN包(SYN=k)，即SYN+ACK包，此时服务器B进入SYN_RECV状态。服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。

第三次握手.
客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK(ACK=k+1)，此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1

完成三次握手，客户端与服务器开始传送数据。

最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。
CLOSED 关闭状态：
为建立建立连接之前的起始点，在连接超时或者连接关闭的时候进入此状态，但是这并不是一个真正的状态，而是这个状态图的假想起点和终点（便于我们思考与理解）。
LISTEN 监听状态：
服务器 server 端等待连接的状态。服务器经过 socket，bind，listen 函数之后进入此状态，开始监听客户端发过来的连接请求。此称为应用程序被动打开（等待客户端的连接请求）。
SYN_SENT 状态：
第一次握手发生阶段，客户端发起连接。客户端调用 connect，发送 SYN 给服务器端，然后客户端进入 SYN_SENT状态，等待服务端的确认（三次握手中的第二个报文）。如果服务器端不能连接，则客户端直接进入 CLOSED 状态。
SYN_RECV 状态：
第二次握手发生阶段，这里是服务器端接收到了客户端的 SYN 请求，此时服务端由 LISTEN 进入 SYN_RECV 状态，同时服务器端回应一个 ACK，然后再发送一个 SYN 即 SYN+ACK 给客户端。状态图中还描绘了这样一种情况，当客户端在发送 SYN 的同时也收到服务器端的 SYN 请求，即两个同时发起连接请求，那么客户端就会从 SYN_SENT 转换到 SYN_REVD 状态。
ESTABLISHED 状态：
第三次握手发生阶段，客户端接收到服务器端的 ACK 包（ACK，SYN）之后，也会发送一个 ACK 确认包，客户端进入ESTABLISHED 状态，表明客户端这边已经准备好，但 TCP 需要两端都准备好才可以进行数据传输。服务器端收到客户端的 ACK 之后会从 SYN_RCVD 状态转移到 ESTABLISHED 状态，表明服务器端也准备好进行数据传输了。
总结：
客户端和服务器端都变为 ESTABLISHED 状态，就可以进行数据的传输了；当然 ESTABLISHED 也可以说是一个数据传送状态。

为什么TCP客户端最后还要发送一次确认呢？
一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
SYN攻击
在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态.
Syn攻击就是 进行攻击的客户端 在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直 至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击
netstat -n -p TCP | grep SYN_RECV
一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.
但是不能完全防范syn攻击。

四次挥手

TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送(报文段4)。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1(报文段5)。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A(报文段6)。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1(报文段7)。

FIN_WAIT_1 状态：
第一次挥手 主动关闭的一方（执行主动关闭的一方既可以是客户端，也可以是服务器端，我们这里以客户端执行主动关闭为例子），终止连接时，发送 FIN 给对方，然后等待对方返回 ACK 。第一次挥手客户端就进入 fin_wait_1状态。
CLOSE_WAIT 状态：
接收到 FIN 之后，被动关闭的一方进入 close_wait 状态。进入该状态的具体动作是接收到客户端发来的 FIN，同时服务端对客户端发送 ACK。
CLOSE_WAIT 状态：
可以理解为被动关闭的一方此时正在等待上层应用程序发出关闭连接指令。
TCP 关闭是全双工过程，这里客户端执行了主动关闭，被动方服务器端接收到 FIN 后也需要调用 close 关闭，这个 CLOSE_WAIT 就是处于这个状态，等待关闭的请求方发送 FIN，发送了 FIN 则进入 LAST_ACK 状态。
FIN_WAIT_2 状态：
主动端（这里是客户端）先执行主动关闭发送 FIN，然后接收到被动方（这里是服务端）返回的 ACK 后进入此状态。
LAST_ACK 状态：
被动方（服务器端）发起关闭请求，发送 FIN 给对方，进入此状态，同时在接收到 ACK 时进入 CLOSED 状态。
CLOSING 状态：
两边同时发起关闭请求时（即主动方发送 FIN，等待被动方返回 ACK，同时被动方也发送了 FIN；主动方接收到了FIN 之后，发送 ACK 给被动方），主动方会由 FIN_WAIT_1 进入此状态，等待被动方返回 ACK。
TIME_WAIT 状态：
从状态变迁图会看到，四次挥手操作最后都会经过这样一个状态然后进入 CLOSED 状态。共有三个状态会进入该状态

由 CLOSEING 状态进入：
同时发起关闭情况下，当主动端接收到 ACK 后，进入此状态，实际上这里的同时是这样的情况：客户端发起关闭请求，发送 FIN 之后等待服务器端回应 ACK，但此时服务器端同时也发起关闭请求，也发送了 FIN，并且被客户端先于 ACK 接收到。
由 FIN_WAIT_1 进入：
发起关闭后，发送了 FIN，等待 ACK 的时候，正好被动方（服务器端）也发起关闭请求，发送了 FIN，这时客户端接收到了先前 ACK，也收到了对方的 FIN，然后发送 ACK（对对方 FIN 的回应），与 CLOSING 进入的状态不同的是接收到 FIN 和 ACK 的先后顺序。
由 FIN_WAIT_2 进入：
这是不同时的情况，主动方在完成自身发起的主动关闭请求后，接收到了对方发送过来的 FIN，然后回应 ACK。

为什么建立连接协议是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的连接请求后，它可以把ACK和SYN(ACK起应答作用，而SYN起同步作用)放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
TIME_WAIT状态由两个存在的理由。
（1）可靠的实现TCP全双工链接的终止。
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
（2）允许老的重复的分节在网络中消逝。
假 设在12.106.32.254的1500端口和206.168.1.112.219的21端口之间有一个TCP连接。我们关闭这个链接，过一段时间后在 相同的IP地址和端口建立另一个连接。后一个链接成为前一个的化身。因为它们的IP地址和端口号都相同。TCP必须防止来自某一个连接的老的重复分组在连 接已经终止后再现，从而被误解成属于同一链接的某一个某一个新的化身。为做到这一点，TCP将不给处于TIME_WAIT状态的链接发起新的化身。既然 TIME_WAIT状态的持续时间是MSL的2倍，这就足以让某个方向上的分组最多存活msl秒即被丢弃，另一个方向上的应答最多存活msl秒也被丢弃。 通过实施这个规则，我们就能保证每成功建立一个TCP连接时。来自该链接先前化身的重复分组都已经在网络中消逝了。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。