TCP基础

目录

TCP报文段：

TCP三次握手

TCP四次挥手

SYN攻击：

socket编程：

超时重传：

窗口机制：

流量控制：

拥塞控制：

TCP的可靠性：

常见问题：

---

TCP报文段：

组成：分为头部和数据两部分。

TCP报文段头部中的字段：

• 源端口/目的端口    这两个字段与IP头部中的源IP地址和目的IP地址一起, 唯一地标识了每个连接。一个ip地址和一个端口的组合被称为一个socket或一个endpoint。
• 序列号(seq)        本报文段所发送的数据的第一个字节的序列号，seq的值等于前面已发送过的数据的最后一个字节的序列号+1。(TCP传输时将每个字节的数据都进行了编号，这个编号就是序列号)
• 确认号(ack)        期望收到对方下一个报文段的第一个数据字节的序列号，若ack为x，则到序号x-1为止(包括x-1)的所有数据都已正确收到。
• 确认(ACK)        仅当ACK=1时，ack字段才有效，当ACK=0时，ack无效。
• 同步(SYN)        SYN=1且ACK=0 表明这是一个连接请求报文段，若对方同意建立连接，则对方应在响应报文中包含SYN=1和ACK=1。
• 终止(FIN)        FIN=1表明此报文的发送方已经结束向对方发送数据，并要求释放连接。
• 重置(RST)         重置连接。
• 窗口大小            接收端接收缓冲区剩余的大小。这是一个16位的字段，单位是字节数。窗口大小字段最大能表示65535个字节(64K)，但是TCP的接收窗口大小最大并不是64K。TCP实际的接收窗口大小为16位窗口大小字段的值左移M(M表示：窗口扩大因子)位，每移一位，窗口扩大两倍。
• 校验和             发送方根据TCP头部和数据来计算校验和，接收方收到数据后，以同样的方式计算校验和，并与发送方的校验和进行对比，若不一致，则直接丢弃TCP报文。目的是保证TCP头部和数据在传输过程中不被修改。

说明：

• 在连接建立后所有传送的报文都必须把ACK置1。
• SYN报文段、FIN报文段不能携带数据，但会消耗掉一个序列号。
• ACK报文段可以携带数据，但如果不携带数据则不消耗序列号。

 

TCP三次握手

概念：建立一个TCP连接时，客户端和服务器需要交互3次，即发送3次TCP报文段，故称为3次握手。

目的：与服务器建立TCP连接，并同步连接双方的序列号、确认号、TCP窗口大小等信息。

说明：
        三次握手改为两次握手会产生死锁：
            两次握手：A发送连接请求报文，B接收A的请求报文并发出确认报文后，则认为连接建立。
            举例：A发送连接请求报文，B收到A的请求报文并发出确认报文，如果B的确定报文在传输过程中丢失了，此时，B认为连接已建立并开始发送数据，而A一直在等待着B的确定报文，且不会接受B发送的数据，而B在发送数据后将一直处于等待A确定的状态中，从而造成A和B相互等待，形成死锁。

第一次握手：
        客户端向服务器发出连接请求报文段(报文段头部：(初始)序列号seq=x、同步SYN=1)，此时客户端进入SYN_SENT(同步已发送)状态。
        说明：同步SYN=1会消耗一个序列号位，即把x这个序列号位给占了，故下次发送的序列号应该从x+1开始，第一次挥手时的FIN也同理。

第二次握手：
        服务器收到连接请求报文段后，若同意建立连接，则向客户端发送响应报文段(报文段头部：同步SYN=1、确认ACK=1、确认号ack=x+1、序列号seq=y，此时服务器进入SYN_RECV(同步已收到)状态。此时的TCP连接称为半连接(half-open connect)。

=第三次握手：
        客户端收到服务器的响应报文段后，再次向服务器发出用于确认的报文段(报文段头部：同步SYN=0、确认ACK=1、确认号ack=y+1、序号seq=x+1)，此时TCP连接已建立，客户端和服务器都进入ESTABLISHED(已建立连接)状态。

TCP四次挥手

概念：释放一个TCP连接时，客户端和服务器需要交互4次，即发送4次TCP报文段，故称为4次挥手。

说明：
        1)断开TCP连接 即 客户端关闭发送数据的通道 并且 服务器关闭发送数据的通道。
        2)为什么连接的时候是三次握手，关闭的时候却是四次握手：
            1>建立连接时：当Server端收到Client端的SYN连接请求报文后，Server端可以直接发送SYN+ACK报文，其中ACK报文是用来应答的，SYN报文是用来同步的。
            2>关闭连接时：当Server端收到Client端的FIN报文后，Server端很可能不会立即关闭SOCKET，而是先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了，但是我(可能)还有数据要发送"，当Server端所有的报文都发送完了，Server端才会发送FIN报文，即Server端通知Client端的过程中需要挥两次手，故在关闭连接的时候总共需要四次挥手。

第一次挥手：
        客户端向服务器发出连接释放报文段(报文段头部：终止FIN=1、序号seq=u)，并停止发送数据，主动关闭TCP连接，此时客户端进入FIN_WAIT1(终止等待1)状态。

第二次挥手：
        服务器收到客户端的连接释放报文段后，向客户端发送确认报文段(报文段头部：确认ACK=1、确认号ack=u+1、序号seq=v)，此时服务器进入CLOSE_WAIT(关闭等待)状态，并通知应用进程。
        客户端收到服务器的确认报文段后，进入FIN_WAIT2(终止等待2)状态。
        此时，客户端已经没有数据要发送了，但是服务器可能还有数据要发送，且客户端依然可以接受服务器发送的数据，此时的TCP连接处于半关闭状态。

第三次挥手：
        应用进程通知服务器释放连接后，服务器发出连接释放报文段(报文段头部：确认ACK=1，终止FIN=1、序号seq=w(在半关闭状态时服务器可能又发送了一些数据)、确认号ack=u+1)，此时服务器进入LAST_ACK(最后确定)状态。

第四次挥手：
        客户端收到服务器的连接释放报文段后，向服务器发送确定报文段(报文段头部：确认ACK=1、序号seq=u+1、确认号ack=w+1)，此时客户端进入到TIME-WAIT(时间等待)状态，等到等待时间过后，二者才都进入到CLOSED(关闭)状态。

 

SYN攻击：

• 概念：SYN攻击是一个典型的DDOS(Distributed Denial of Service:分布式拒绝服务)攻击。
• 原理：
•         客户端在短时间内伪造大量不存在的IP地址，然后向服务器不断地发送SYN包(即不断地发起第一次握手，建立大量的半连接状态的请求)，
•         服务器收到连接请求后发送响应报文，并等待客户的确认，由于源地址是不存在的，故服务器需要不断的重发直到超时，
•         这些伪造的SYN包将长时间占用未连接队列(syns queue)，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
• 检测：
•         查看状态为SYN_RECV的TCP连接：    netstat -npt | grep SYN_RECV   # 若Foreign Address的ip地址是随机的，则服务器此时很可能正在被SYN攻击。
•         统计TCP连接的状态：            netstat -npt | awk '{print $6}' | grep -v "Foreign" | sort | uniq -c
• 说明：一般较新的TCP/IP协议栈都对这一过程进行修正来防范SYN攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.但是不能完全防范SYN攻击。

    

socket编程：

• Socket.connect()    会触发TCP的三次握手。
• Socket.close()         会触发TCP的四次挥手。表示不发送数据也不接受数据了。

 

超时重传：

• 概念：TCP传输数据时，发送方发送数据后会等待接收方响应的ACK报文，并根据ACK报文来判断数据是否传输成功。如果发送方发送完数据后，长时间没有等到接收方的ACK报文，那么发送方会重新发送这些数据。
• 发送方没有收到ACK报文的原因：
•         数据在传输过程中由于网络原因等直接全体丢包，接收方根本没有接收到。
•         接收方接收到了响应的数据，但是响应的ACK报文却由于网络原因丢包了。之后接收方若再次收到发送方重新发送的数据(根据序列号可判断是否是重复数据)，则会将这些重复的数据丢弃，但是仍然会响应ACK报文。
• 超时时间的计算：
•         默认500ms，重发一次后，若仍没有响应，那么等待2*500ms的时间后，再次重传。重传的次数达到某个值后，TCP就认为网络已经断了或对方出现异常了，然后强制关闭连接。
•         超时时间过长会降低TCP传输的整体效率。超时时间过短会导致频繁的发送重复的包。

 

窗口机制：

• 概念：每个TCP连接的两端都维护了一个发送窗口和一个接收窗口。
• 发送窗口：
•         发送方的发送缓存内的数据都可以被分为4类，其中类型2和类型3属于发送窗口：
•             1>已发送，已收到ACK 
•             2>已发送，未收到ACK 
•             3>未发送，但允许发送 
•             4>未发送，但不允许发送
• 接收窗口：
•         接收方的缓存数据分为3类，其中类型2属于接收窗口：
•             1>已接收 
•             2>未接收但准备接收 
•             3>未接收而且不准备接收
• 滑动机制：
•         发送窗口只有收到发送窗口内字节的ACK确认后，才会移动发送窗口的左边界。
•         接收窗口只有在前面所有的报文段都确认的情况下才会移动左边界。
•         若接收窗口前面还有字节未接收，此时如果收到后面的字节，则接收窗口不会移动，TCP也不会对后面的字节发送确认，发送方超时后会重传这些数据。

    

流量控制：

• 概念：TCP根据接收端对数据的处理能力(窗口大小字段的值)来决定发送端的发送速度。
• 过程：
•         接收端在确认应答时发送ACK报文，ACK报文中包含了自己接收窗口的大小，发送方根据ACK报文里窗口大小的值的来设定自己发送数据的速度。
•         若ACK报文中窗口大小的值为0，那么发送方将停止发送数据，并定期向接收端发送窗口探测数据段，以便及时地获取接收端最新窗口大小的值。
• 说明：如果发送端发送的数据太快，则接收端的接收缓冲区很快就会被填满，接受端的接收缓存区被填满后，发送端再发送的数据就会被接收端丢弃，进而触发发送端的超时重传。

    

拥塞控制：

• 概念：路由器因无法处理高速率到达的流量而被迫丢弃数据的现象称为拥塞。
•         拥塞的原因：当路由器在单位时间内接收到的数据量大于其可发送的数据量时，路由器就需要把多余的数据存储起来。若接收到的数据量持续大于可发送的数据量，那么会耗尽路由器的存储资源，导致路由器丢弃部分数据。
• 原理：发送方维持一个拥塞窗口变量cwnd，拥塞窗口的大小取决于网络的拥塞程度，发送方的发送窗口大小取 拥塞窗口的大小 和 接收端的接收窗口大小 的较小值，TCP通过动态地调整发送窗口的大小来实现拥塞控制。
• 慢启动机制：
•         拥塞窗口的初始值为1，发送方每次收到ACK报文后，将拥塞窗口的值加1。
•         慢启动中的"慢"，表示刚开始发送的数据少，发送的速度慢，但是拥塞窗口值的增长是指数级别的增长，故增长的非常快。当拥塞窗口的值达到阈值时，拥塞窗口值的增长就改为线性增长。
•         在慢启动开始的时候，慢启动的阈值等于窗口的最大值，TCP一旦发现网络拥塞，慢启动的阈值将会变为当前阀值的一半，同时拥塞窗口重置为1。

TCP的可靠性：

•  连接管理：三次挥手四次握手
• 传输数据：
•         序列号和确认号机制
•         校验和
•         超时重传机制
• 流量控制
• 拥塞控制

 

常见问题：

服务器返回“RST”的问题：
    分析：服务器关闭connection后，若客户端还在connection上读写，服务器内核接收到数据后发现Socket已经close了，此时服务器会返回“RST”标志给客户端。
    说明：
        服务器返回了“RST”时，若此时客户端正在从Socket套接字的输出流中读数据则会提示Connection reset”
        服务器返回了“RST”时，若此时客户端正在往Socket套接字的输入流中写数据则会提示“Connection reset by peer”

    解决：重试。