计算机网络课件第五章 传输层.pptVIP

5.8 TCP的连接管理 5.8 TCP的连接管理 一、简介 TCP传输连接有三个阶段 ① 连接建立 ② 数据传送 ③ 连接释放 连接建立过程中要解决三个问题： 使每一方能够确知对方的存在 允许双方协商一些参数(如最大报文段长度、最大窗口大小、服务质量等) 能够对传输实体资源进行分配(如缓存、连接表中的项目等) TCP 连接的建立都是采用客户/服务器方式 客户(client)：主动发起连接建立的应用进程 服务器(server)：被动等待连接建立的应用进程 二、TCP 的连接建立 TCP连接的建立采用三次握手(three-way handshake) A向B发出连接请求报文段，其首部中的SYN=1，并选择序号seq=x，表明传送数据时的第一个数据字节的序号是x B收到连接请求后，如同意，则发回确认，其中SYN=1，ACK=1，确认号ack=x+1，自己选择的序号seq=y A收到后向B给出确认，其ACK=1，确认号ack=y+1 B收到后，TCP连接建立 SYN = 1, seq = x ACK = 1, seq = x + 1, ack = y ? 1 CLOSED CLOSED 数据传送 主动打开 被动打开 A B 客户 服务器 SYN = 1, ACK = 1, seq = y, ack= x ? 1 SYN-SENT ESTABLISHED ESTABLISHED SYN-RCVD LISTEN 5.8 TCP的连接管理 二、TCP 的连接建立 关于3次握手的讨论 为什么要采用3次握手而不是2次握手？ 防止“失效的连接请求”在服务器端占用资源 客户端发出了连接请求，但该数据报在网络中某处滞留了 客户端等待超时后，重发连接请求，服务器响应，建立连接 滞留的连接请求又到达服务器端，如果采用2次握手，服务器将建立一个连接，分配资源(缓冲区、定时器、…) ? 占用资源且长期存活 安全问题：专门针对3次握手的TCP SYN Flooding攻击 攻击者连续发送大量SYN报文，但却不对SYN ACK报文做出响应 结果：服务器内部数据结构满，无法对正常用户的TCP连接请求做出响应 此类攻击大多使用IP地址伪装，使得对攻击源的定位比较困难 Linux内核采用了SYN_Cookies机制应对这种攻击 三、TCP的连接释放 连接的释放可由任一方发起 (假定A主动关闭连接)A发送报文段，其首部的 FIN=1，序号seq=u B发出确认，ACK=1，确认号ack=u+1，序号seq = v FIN = 1, seq = u 数据传送 A B 客户 服务器 ACK = 1, seq = v, ack= u ? 1 A?B方向的连接被释放，此时连接处于半关闭状态，B若发送数据，A仍要接收 若B已经没有要向A发送的数据，就向A发送连接释放报文(FIN=1, ACK=1) A收到后，发出确认，其中ACK=1，确认号ack=w+1，序号seq=u+1 TCP连接必须经过时间2MSL后才真正释放掉 FIN = 1, seq = u ACK = 1, seq = u + 1, ack = w ? 1 CLOSED CLOSED 数据传送 主动关闭 被动关闭 A B 客户 服务器 ACK = 1, seq = v, ack= u ? 1 数据传送 FIN = 1, ACK = 1, seq = w, ack= u ? 1 ESTABLISHED FIN_WAIT_1 ESTABLISHED LAST_ACK CLOSE_WAIT FIN_WAIT_2 TIME_WAIT 等待2MSL 通知 应用 进程 5.8 TCP的连接管理 三、TCP 的连接释放 关于MSL Maximum Segment Lifetime，报文段最大存活时间 RFC793中建议MSL=2分钟，一般使用更小的值 关闭连接前等待2MSL时间的原因 为了保证A发送的最后一个ACK报文段能够到达B 防止“已失效的连接请求报文段”出现在本连接中 A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段，都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段 TCP的有限状态机 粗实线：客户进程的正常变迁 粗虚线：服务器进程的正常变迁 细线：异常变迁 CLOSED ESTABLISHED LISTEN CLOSE_WAIT FIN_WAIT_1 SYN_RCVD FIN_WAIT_2 CLOSING TIME_WAIT SYN_SENT LAST_ACK 主动打开 被动打开 被动关闭 主动关闭 起点 被动打开 主动打开 发送 SYN 同时打开 收到 SYN，发送 SYN, ACK 收到 ACK 数据传送