TCP基础知识有哪些

39次阅读

共计 4872 个字符，预计需要花费 13 分钟才能阅读完成。

本篇内容介绍了“TCP 基础知识有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

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 三次握手

概念：建立一个 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”