运输层有两个主要协议
1.用户数据报协议UDP（User Datagram Protocol）
2.传输控制协议TCP（Transmission Control Protocol）
UDP在传送数据之前
不需要先建立连接
。远地主机的运输层在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某种情况下UDP却是一种最有效的工作方式。 所以我们通常说UDP是不可靠的。
TCP则
提供面向连接的服务
。在传输数据之前必须先建立连接，数据传送结束后要释放连接。由于TCP要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多开销，如确认、流量控制、计时器以及
连接管理
等。 所以我们说TCP是可靠的。
本文的TCP三次握手，四次挥手就属于
TCP的运输连接管理
TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即：
连接建立、数据传送和连接释放
。运输连接的管理就是使运输连接的建立和释放都能正常的进行。
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。
主动发起连接建立的应用进程叫做
客户
，而被动等待连接建立的应用进程叫做
服务器
。
通俗来讲，
A对B说，我想和你建立连接，等B回信
B听见了，同意了，对A说，我听见了，咱们建立连接吧，然后等A给我再回个信，我就敞开大门
A听见了B说的，我也听见了，我已经准备好了，来吧~
B收到A的回信了，也敞开了大门~
所下图所示：
客户端A发起连接请求报文段，TCP客户进程进入SYN-SENT（同步已发送）状态。
服务器端收到连接请求，如果同意连接，向A发送确认报文段,TCP服务器进程进入SYN-RCVD（同步收到）状态。
TCP客户进程收到B的确认后，还要向B给出确认，此时TCP连接已经建立，A进入ESTAB-LISHED（已建立连接）状态。
当B收到A的确认后，也进入ESTAB-LISHED（已建立连接）状态。
上述连接建立过程叫做三次握手。
解释一下为什么不能两次握手：
防止失效的连接请求报文段被服务端接收，从而产生错误。
PS：失效的连接请求：若客户端向服务端发送的连接请求丢失，客户端等待应答超时后就会再次发送连接请求，此时，上一个连接请求就是『失效的』。
若建立连接只需两次握手，客户端并没有太大的变化，仍然需要获得服务端的应答后才进入ESTABLISHED状态，而服务端在收到连接请求后就进入ESTABLISHED状态。此时如果网络拥塞，客户端发送的连接请求迟迟到不了服务端，客户端便超时重发请求，如果服务端正确接收并确认应答，双方便开始通信，通信结束后释放连接。此时，如果那个失效的连接请求抵达了服务端，由于只有两次握手，服务端收到请求就会进入ESTABLISHED状态，等待发送数据或主动发送数据。但此时的客户端早已进入CLOSED状态，服务端将会一直等待下去，这样浪费服务端连接资源。
下次再写四次挥手吧~
—————————————————————————————————————————
TCP的连接释放
TCP的连接释放采用四报文握手机制。
任何一方都可以在数据传送结束后发出连接释放的通知
，待对方确认后就进入半关闭状态。当另一方也没有数据再发送时，则发送连接释放通知，对方确认后就完全关闭了TCP连接。
通俗来讲，
就是A对B说，我要和你断开连接了，我不发数据给你了，你要发数据给我就快点哈，
B听见了，对A说我听见了，
然后赶紧发数据，发完之后，
对A说我也发完了，
A收到后，对B说，我听见了，等等我就关了。
B听见A说的，放心了，就关了。
过了一会，A也关了。
现在A和B都处于ESTAB-LISHED（已建立连接）状态。
A的应用进程先向其TCP发送连接释放报文，并停止再发送数据，主动关闭TCP连接。
此时A进入FIN-WAIT-1（终止等待1）状态。
B收到连接释放报文段后即发出确认，然后B进入CLOSE-WAIT（关闭等待）状态。
此时TCP连接已经处于
半关闭
（half-close）状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一段时间。
A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发送连接释放报文段。
此时B就进入了LAST-ACK（最后确认）状态，等待A的确认。
A在收到B的释放连接释放报文段后，必须对此发出确认。然后进入到TIME-WAIT（时间等待）状态。
现在TCP连接还没有释放掉。必须经过时间等待器（TIME-WAIT timer）设置的时间2MSL后，A才进入到CLOSED状态。
时间MSL叫做
最长报文段寿命
B收到A的最后一个报文段也进入CLOSED状态。 B结束TCP连接的时间要比A早一些。
解释一下为什么A在TIME-WAIT状态必须等待2MLS的时间：
第一，为了保证A发送的最后一个ACK报文段能够到达B。
当这个ACK报文段丢失时
，B会超时重传FIN-ACK报文段，而A就能在
2MSL时间接收这个重传的FIN-ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后A和B都正常进入到CLOSED状态。如果A不等，就无法收到B重传的FIN-ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。
第二，防止失效的连接请求，A在发送完最后一个ACK报文段后，再经过2MSL。就可以使本连接持续时间内所产生的所有报文段都从网络消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。
为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
下面谈一谈攻击~（粗略的讲一下）
—————————————————————————————————————————
SYN攻击
-
什么是 SYN 攻击（SYN Flood）？
在三次握手过程中，服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后，服务器才能转入 ESTABLISHED 状态.
SYN 攻击指的是，攻击客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN包，服务器回复确认包，并等待客户的确认。由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，导致目标系统运行缓慢，严重者会引起网络堵塞甚至系统瘫痪。
SYN 攻击是一种典型的 DoS/DDoS 攻击。
-
如何检测 SYN 攻击？
检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。
-
如何防御 SYN 攻击？
SYN攻击不能完全被阻止，除非将TCP协议重新设计。我们所做的是尽可能的减轻SYN攻击的危害，常见的防御 SYN 攻击的方法有如下几种：
- 缩短超时（SYN Timeout）时间
- 增加最大半连接数
- 过滤网关防护
- SYN cookies技术