盒子
盒子
文章目录
  1. TCP 握手机制 – 3次握手
    1. 为什么需要三次握手
  • TCP 握手机制 连接终止协议 – 4次挥手
    1. TCP 连接异常终止分析
  • TCP 优化
  • Networking TCP/UDP Sockets

    TCP 握手机制 – 3次握手

    1. 第一次握手,报文1
      客户端发送一个报文段到到服务器带有SYN标志,将SYN位置设置为1, sequence number 设置为 x, 然后客户端进入 SYN_SEND 状态,等待服务器确认。

    2. 第二次握手,报文2
      服务器端收到SYN报文段,对这个SYN报文段进行确认,设置acknowledge number 为 x + 1, 同时自己还要发送一个SYN 请求信息,将SYN位置设置为1, sequence
      number设置为Y。服务器将这个SYN + ACK报文段一起发送给服务器端,此时服务器进入 SYN_RECV状态。(SYN_RECV状态很短,基本上用netstat很难看到)

    3. 第三次握手,报文3
      客户端收到服务器端端SYN+ACK报文段,然后将acknowledge number设置为 y + 1,向服务器发送Ack报文段。之后,服务器端和客户端都进入Established状态。

    为什么需要三次握手

    “网络中存在延迟的重复分组”或者“为了防止已尽失效的连接请求报文段”突然又传送到了服务器端,因而产生错误。

    已尽失效的连接请求报文段 产生的情况,以及如果只有2次挥手会有什么后果:

    Client发出的第一个连接请求报文段并没有丢失,而是在某个网络节点长时间滞留了,以至延误到TCP连接释放后的某个时间才到达Server。这个本来是一个失效的报文段,但是server收到后,就误认为是Client再次发出的新的连接请求,于是就向client发出确认报文段,同意建立连接。但是事实上,Client并没有发出新的连接请求,因此不会理睬server的确认报文段,也不会向server发送数据。但是server却认为新的连接已经建立,并一直等待client发来数据,这样,server的很多资源就白白的浪费掉。

    采用三次握手后,Client不会向server发出的这个报文段(含SYN和ACK)发回ACK,Server由于收不到Ack,就知道
    Client此时并没有发出这个新的要求建立连接的请求,从而防止server端一直等待,浪费资源。

    TCP 握手机制 连接终止协议 – 4次挥手

    由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。 这原则是当一方完成它的数据发送任务后就能发送一个
    FIN来终止这个方向的连接。收到一个FIN 只意味着这一方向上没有数据流动,一个 TCP 连接在收到一个 FIN 后仍
    能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。

    1. 第一次挥手
      主机1,
      设置 sequence number和acknowledge number,
      向主机2发送一个 FIN 报文段,
      此时,主机1 进入 FIN_WAIT_1 状态,
      这表示主机1没有数据要发送给主机2

    2. 第二次挥手
      主机2,
      收到主机1发送到 FIN 报文段,
      向主机1 回一个 ACK 报文段, Acknowledge Number 设置为 Sequence Number 加 1,
      主机1 进入 FIN_WAIT_2 状态,
      这表示主机2同意主机1点关闭请求

    3. 第三次挥手
      主机2,
      向主机1 发送 FIN 报文段,请求关闭连接,
      同时主机2 进入 LAST_ACK 状态。

    4. 第四次挥手
      主机1
      收到主机2发送到 FIN 报文段,
      向主机2 发送 ACK 报文段,
      然后主机1 进入 TIME_WAIT状态,
      主机2 收到 主机1的 ACK报文段后,就关闭连接。
      此时,主机1 等待 2 MSL后依然没有收到回复,
      这证明 Server 端正常关闭,则主机1 也可以关闭连接。

    • MSL: Maximum Segment Lifetime, is the time a TCP segment can exist in the internnet work systems.

    TCP 连接异常终止分析

    有一种能够释放 TCP 连接的机制,是TCP的reset 报文。TCP正常释放连接通过四次挥手完成,下面列出某种异常情况,使得TCP连接释放失败,
    从而继续占用系统的部分资源。

    1. 客户端尝试与服务器未对外提供服务的端口建立TCP连接,服务器将会直接向客户端发送reset报文
    2. 客户端和服务器的某一方在交互的过程中发生异常(如程序崩溃),该方系统将向对方发送TCP reset报文,告知对方释放相关的TCP连接
    3. 接收端收到TCP报文,但是发现该TCP的报文,并不在其已经建立的TCP连接表里,则直接向对方发送reset报文
    4. 在交互的双方的某一方长期未收到来自对方的确认报文,则其在超出一定的重传次数或者时间后,会主动向对方端口发送reset报文,释放该TCP连接
    5. 有些应用开发者在设计应用系统的时候,会利用reset报文快速释放已经完成的数据交互的TCP连接,以提高业务交互的效率

    Reset报文的利用

    1. 安全设备利用reset报文阻断异常连接
    2. 利用reset报文实施攻击,

    TCP 优化

    High Performance Brower Networking by llya Grigorik

    Keywords:
    Flow Control, Slow Start, BDP ( Bandwidth-delay Product), RWND (Receiver Window)

    1. Flow Control
      问题: 传输数据的时候,如果发送方传输的数据量超过了接收方的处理能力,那么接受方会出现丢包。
      解决方法: 数据传输双方在交互时候声明各自的接受窗口的大小,【rwnd】 用来表示自己最大能够保存多少数据,这主要是针对接受方而言,
      如果窗口衰减到零,还继续发包,则会发生丢包。
    1. Slow Start
      虽然流量控制可以避免发送方过载接受方,却无法避免网络过载。因为接受窗口,只反应了服务器个体的情况,却无法反映网络整体的情况。
    • 拥塞窗口 [cwnd]:用来表示发送方在得到接受方确认前,最大运行传输的未经确认的数据

    • [cwnd] 和 [rwnd] 不同: 发送方的一个内部参数,无需通知接受方。其初始值比较小,然后随着数据包被接受方确认,窗口成倍增大。

    在慢启动的过程中,随着[cwnd] 的增加,可能会出现网络过载,其外在表现就是丢包。一旦出现,[cwnd] 的大小会迅速衰减,以便网络能够缓过来。

    支持一下
    扫一扫,支持forsigner
    • 微信扫一扫
    • 支付宝扫一扫