TCP UDP TCP三次握手

TCP

TCP（Transfer Control Protocol）传输控制协议，是一种面向连接的保证可靠传输的协议。

在TCP/IP协议中

• IP层主要负责网络主机的定位，数据传输的路口，有IP地址可以唯一确定Internet上单一台主机

• TCP层提供面向应用的数据传输机制

发送方和接收方的成对的两个socket之间必须建立连接， 通过TCP协议得到的是一个顺序的无差错的数据流

TCP是一个基于连接的协议，能够提供两台计算机之间的可靠的数据流

UDP

UDP（User Datagram Protocol）用户数据报协议，是一种无连接的协议 。

UDP是发送一种称为数据报的独立数据包的协议，该协议并不保证数据报是否能正确的到达目的地，它是一个非面向连接的协议。

每个数据报都是一个独立的信息，包括完整的源地址或目的地址，他在网络上以任何可能的路径转往目的地，因此能否到达目的地，到达时间以及内容的正确性都不能保证。

TCP&&UDP

• TCP它是一个面向连接的传输协议，它在socket之间进行数据传输之前必然要先建立连接 。

UDP的每个数据报中都给出了完整的地址信息，在传输时无需建立发送方和接收方的连接。

• TCP是一个可靠的协议，它保证接收方完全正确的获取发送方所发的全部数据。

  UDP是一个不可靠的协议，他无法保证发送方的数据是否完全正确的被接收方接受，发送方的数据并不一定 以相同的次序到达接收方

• UDP的传输效率大于TCP。

• TCP传输数据时没有大小限制，一旦连接建立起来，双方的socket的就可以按统一的格式传输大量的数据。

UDP传输数据时是有大小限制的，每个数据报必须限定在64KB之间。

TCP的三次握手和四次挥手

SYN(synchronous建立联机)

ACK(acknowledgement 确认)

FIN(finish结束)

Sequence number(顺序号码)

Acknowledge number(确认号码) 

三次握手

TCP是一个面向连接的协议，在正式发收数据前，必须和对方建立可靠的连接，而一个TCP连接必须经过三次握手才能建立起来。

1. 第一次握手：建立连接时，Client发出SYN包（SYN=1，随机产生一个seq=j）到Server，并进入SYN_SEND状态，等待Server确认。

2. 第二次握手：Server收到SYN包，确认Client的SYN，知道Client请求建立连接，将ACK置为1（ACK=1,ack=j+1），同时自己也发送一个SYN包（SYN=1,seq=k），即SYN+ACK包，此时服务端B进入SYN_RECV状态。

3. 第三次握手：Client收到Server的SYN+ACK包，检验ACK是否为1，ack是否为j+1,正确则向Server发送确认包ACK（ACK=1,ack=k+1），Server确认ACK与ack，正确则建立连接成功，Client和Server进入ESTABLISHED状态，完成三次握手。

三次握手的特点：没有应用层的数据

为什么会采用三次握手
采用三次握手是：为了防止失效的连接请求报文段突然又传送到server，因而产生错误。
                 失效的连接请求报文段：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。
若将三次握手改为两次握手会怎么样？把三次握手改成仅需要两次握手，死锁是可能发生的。假定C给S发送一个连接请求分组，S收到了这个分组，并发送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁


四次挥手

TCP连接是全双工的，每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接，收到一个FIN只意味着这个方向上没有数据流动，即不会再收到数据了，但在这个TCP连接上仍能发送数据。首先关闭的一方将执行主动关闭，而另一方执行被动关闭。

1. Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT状态

2. Server收到FIN后，发送一个ACK给Client,确认序号为收到序号+1，Server进入CLOSE_WAIT状态

3. Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态

4. Client收到FIN后，进入TIME_WAIT状态，接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态，完成四次挥手。

为什么握手三次，而挥手要四次

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的

为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文

DDOS攻击：
客户端不断的向服务端发送连接请求，但又不同意建立连接。
第一步：客户端向服务器端发送连接请求数据包（1） 
第二步：服务器向客户端回复连接请求数据包（2），然后服务器等待客户端发送tcp/ip链接的第三步数据包(3) 
第三步：如果客户端不向服务器端发送最后一个数据包(3)，则服务器须等待30s到2min中才能将此链接进行关闭。当大量的请求只进行到第二步，而不进行第三步，服务器又大量的资源等待第三个数据包。则造成DDos攻击。

DDOS预防（没有根治的办法，除非不使用TCP/IP连接）
1. 关闭不必要的服务
2. 限制同时打开SYN的半连接数目
3. 设置防火墙
4. 缩短服务器等待的时长