所有分类
  • 所有分类
  • 未分类

TCP–三次握手和四次挥手

简介

本文介绍TCP的三次握手和四次挥手。即:TCP建立连接和断开连接的过程。

三次握手

流程图

主机 A为客户端,主机B为服务端。

正式的流程描述

  • 第一次握手
    • A 发送同步报文段(SYN) 请求建立连接。
    • A进入SYN-SENT(同步已发送)状态。
  • 第二次握手
    • B 监听到连接请求, 向 A 发送针对 SYN 的确认 ACK, 同时 B 也发送自己的请求建立连接(SYN) 。
    • B进入SYN-RCVD (同步收到)状态
  • 第三次握手
    • A 收到 B 发出的 SYN,给出确认应答 ACK。
    • A 收到确认后进入 ESTABLISHED (己建立连接)状态。B 收 到 A 的确认后,也进入ESTABLISHED状态

通俗的流程描述

A:向B发送数据:我想跟你(B)建立连接,收到请回复。
B:向A响应数据:好的,可以建立连接。你收到信息后请确认一下,我就跟你建立连接。
A:收到B的确认,将状态置为已连接。向B响应数据:好了,我收到了,请你建立连接吧。
B:收到A的确认,将状态置为已连接。

TCP为什么要三次握手而不是两次

如果是 2 次(即:没有第3次握手)

  1. 网络延迟导致服务端建立连接,而客户端没建立连接
    1. 客户端发出一个请求报文段,它滞留在了某个网络节点, 过了好长时间才发送到服务端, 此时服务端建立连接。 但是由于现在客户端并没有发出连接请求, 因此不会理睬服务端的确认, 而服务端以为新的连接产生, 服务端的资源被浪费。
  2. 如果服务端的ACK丢失,会导致客户端一直重试,服务端会连接大量无效连接
    1. 当服务端的确认应答 ACK 总是丢失时, 客户端以为服务端没有连接, 它将会不断地重新请求连接,而服务端会连接大量的无效连接, 给服务器增加维护成本, 服务器很容易受到 SYN 洪水攻击。

四次挥手

流程图

正式的流程描述

  • 第一次挥手
    • 当主机 A 发送数据完毕后, 发送 FIN 结束报文段。
  • 第二次挥手
    • 主机 B 收到 FIN 报文段后, 向主机 A 发送一个确认序号 ACK(为防止这段时间内, 对方重传 FIN 报文段) 。
  • 第三次挥手
    • 主机 B 准备关闭连接, 向主机 A 发送一个 FIN 结束报文段。
  • 第四次挥手
    • 主机 A 收到 FIN 结束报文段后, 进入 TIME_WAIT 状态。 并向主机 B 发送一个ACK 表示连接彻底释放。

通俗的流程描述

A:向B发送数据:我想跟你(B)断开连接,收到请回复。
B:向A响应数据:好的,准备断开连接,不过我还有些数据没发送完,我发送完之后跟你说。
B:向A响应数据:断开连接吧,我数据处理完了,收到请回复,我收到你的回复后也会断开连接。
A:收到B的确认,开始断开连接。向B响应数据:好了,我收到了,请你断开连接吧。
B:收到A的确认,将状态置为已断开

TCP为什么是四次挥手

  1. 当客户端发送 FIN 结束报文段时,服务端并不会立即关闭 SOCKET(服务端会先通知应用进程,应用进程再关闭),所以只能先发送一个 ACK。(因为有可能此时服务端还有数据没发送完)
0

评论0

请先

显示验证码
没有账号?注册  忘记密码?

社交账号快速登录