TCP/IP知识总结-0

学习TCP/IP，一定要看这个图。它对排除和定位网络或系统故障时大有帮助。

传输控制协议TCP简介： 1.面向连接的，可靠的，基于字节流的传输层通信协议。 2.将应用层的数据流分割成报文段并发送给目标节点的TCP层。 3.数据包都有序号，对方收到则发送ACK确认，未收到则重传。如果发送端d在RTT(一个连接的往返时间，即数据发送时刻到接收到确认的时刻的差值)未收到确认，对应的数据会假设被丢失。 4.TCP用奇偶校验函数来校验检验数据在传输过程中是否有误。

TCP Flags: 1.URG：紧急指针标志。 2.ACK：确认序号标志。 3.PSH：push标志。 4.RST：重置连接标志。 5.SYN：同步序号，用于建立连接过程。 6.FIN：finish标志，用于释放连接。 用于建立连接过程，在连接请求中， SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认域，即SYN=1和ACK=1(捎带是指对客户机到服务器数据的确认被装载在一个承载服务器到客户机的数据报文段中)

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

第一次握手:建立连接时，客户端发送SYN包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认。

第二次握手：服务器收到SYN包，必须确认客户的SYN(ack=x+1)，同时自己也发送一个SYN包(seq=y)，此时是SYN+ACK包，此时服务器进入到SYN_RECV状态。

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(seq = x+1，ack = y+1)。此包发送完毕后，客户端和服务器进入到ESTABLISHED状态完成三次握手。

为什么需要三次握手才能建立起连接？是因为为了初始化Sequence Number的初始值。

首次握手的隐患-SYN超时，Server收到Client的SYN，回复SYN-ACK的时候未收到ACK的确认。Server不断的重试直到超时，Linux默认等待63秒才断开连接。那这样让服务器遭到SYN Flood的攻击，恶意程序会给SYN报文，然后就下线了。然后服务器默认要等待63s才会断开连接。这样攻击者会把服务器的SYN连接队列耗尽，让正常连接的请求不能得到处理。

针对SYN Flood的防护措施： 1.SYN队列满后，通过tcp_syncookies(源地址端口+目标地址端口+时间戳)参数回发SYN Cookie 2.若为正常连接则Client会回发Syn Cookie，直接建立连接。就算本次请求不在Syn队列中也能正常建立连接。

建立连接后，Client出现故障怎么办?可以使用保活机制： 1.向对方发送保活探测报文，如果未收到相应则继续发送。 2.尝试次数达到保活探测数仍未收到响应则中断连接。

TCP采用了四次挥手来释放连接

第一次挥手：Client发送了一个FIN，用于关闭Client到Server的数据传输，Client既然怒到FIN_WAIT_1状态。

第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1(与SYN相同，一个FIN占用一个序号)，Server进入CLOSE_WAIT状态。

第三次挥手：Server发送一个FIN，用于关闭Server到Client的数据传送，Server进入到LAST_ACK状态。

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

为什么会有TIME_WAIT状态？ 1.确保有足够的时间让对方收到ACK包。如果被关闭的一方没有收到ACK，会触发被关闭的一方重发FIN包，就是2MSL。 2.避免新旧连接混淆。

为什么需要四次握手才能断开连接？因为全双工，发送方和接收方都需要FIN报文和ACK报文。

为什么会出现CLOSE_WAIT状态的原因？ 1.对方关闭Socket连接，我方忙于读或写，没有及时关闭连接。(检查代码，特别时释放资源的代码。检查配置，特别是处理请求的线程配置)

UDP的特点： 1.面向非连接。 2.不维护连接状态，支持同时向多个客户端传输相同的消息。 3.数据包报头只有8个字节(TCP是20个字节)，额外开销较小。 4.吞吐量只受限于数据生成速率，传输速率以及机器性能。 5.尽最大努力交付，不保证可靠交付，不需要维持复杂的连接状态表。 6.面向报文，不对应用程序提交的报文信息进行拆分或者合并。

TCP 和UDP的区别： 1，TCP是面向连接(Connection oriented)的协议，UDP是无连接(Connection less)协议； 2，TCP无界，UDP有界； 3，TCP可靠，UDP不可靠；由于TCP要保证所有的数据包都可以到达，所以，需要有重传机制（快重传，快恢复，超时重传），UDP不会进行重传。 4，TCP有序，UDP无序；消息在传输过程中可能会乱序，后发送的消息可能会先到达，TCP会对其进行重排序，UDP不会。 5，TCP有流量控制（拥塞控制），UDP没有； 6，TCP的头部比UDP大；TCP头部20 bytes

RTT(Round Trip Time):发送一个数据包到收到对应的ACK所花费的时间。 RTO(Retransmission TimeOut)：重传时间间隔。

滑动窗口协议，是TCP使用的一种流量控制方法。该协议允许发送方在停止并等待确认前可以连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。 只有在接收窗口向前滑动时（与此同时也发送了确认），发送窗口才有可能向前滑动。