TCP 连接

TCP 连接建立——三次握手

#

为什么需要三次握手#

  • 避免重复建立连接:
    • 如果采用两次握手:客户端发送请求建立连接报文,由于各种原因(网络拥塞、远链路)超时了,客户端发出第二个请求建立连接报文,并且第二个报文率先到达服务端,服务端正常返回 ACK。 此时,第一个请求报文终于到达服务端,服务端返回 ACK,认为连接以建立,等待客户端发送数据,但客户端此时已经建立好连接,不会进行任何响应,导致服务端傻傻等待
      • 三次握手:客户端应当给出第二次响应,如果服务端接收不到这个响应就释放,避免傻傻等待
  • 确保通信的全双工性:TCP 协议工作在全双工模式下,因此确保双方都可以正常发送和接收消息,通过 ack 和 seq 的值实现,双方都给对方发送一个序列号 seq,并给对方返回一个 ack 值等于 seq + 1

TCP 连接关闭——四次挥手#

为什么需要四次挥手#

  • 由全双工衍生出的问题:客户端发送关闭请求,只能说明客户端要发送的消息结束了,并不能说明服务端要发送的消息也结束了,因此还要等待服务端告知客户端自身的消息也发完了(CLOSE-WAIT 状态)
  • 为什么客户端在接收到第二个确认报文后要等待 2MSL
    • 确保连接能够关闭:如果中间报文发生了丢失,服务端就不能正常关闭,因此要等待 2MSL 以确保能接收到服务端重发的报文,完成关闭流程
    • 确保数据报文过期:各种原因没有按预期到达通信双方的数据报文,会在 2MSL 内过期,这样在关闭连接时,网络上双方关于本次连接的数据报文也都消失了

可靠传输#

TCP 可靠传输的实现

  • 确认与重传:自动重传-停止等待协议 ARQ
  • 数据校验
  • 流量控制:滑动窗口
  • 拥塞控制:拥塞窗口
    • 慢开始:指数开始
    • 拥塞避免:超过门限值,线性增长,触发拥塞时直接砍到底进行慢开始
    • 快恢复:上面直接砍到底太粗暴了,改外计算一个新的门限值,窗口大小降到这个值
    • 快重传:连续收到 3 个重复确认包,立刻重传,而不等待超时时间

ARQ协议#

  • RTT 就是数据从网络一端传送到另一端所需的时间,也就是包的往返时间。

  • 超时重传时间是以 RTO (Retransmission Timeout 超时重传时间)表示

自动重传请求(Automatic Repeat-reQuest,ARQ)是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议#

  • 停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认(回复ACK)。如果过了一段时间(超时时间后),还是没有收到 ACK 确认,说明没有发送成功,需要重新发送,直到收到确认后再发下一个分组;
  • 在停止等待协议中,若接收方收到重复分组,就丢弃该分组,但同时还要发送确认;

优点: 简单

缺点: 信道利用率低,等待时间长

1) 无差错情况:

发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。

2) 出现差错情况(超时重传):

停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为 自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组,就丢弃该分组,但同时还要发送确认。连续 ARQ 协议 可提高信道利用率。发送维持一个发送窗口,凡位于发送窗口内的分组可连续发送出去,而不需要等待对方确认。接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组位置的所有分组都已经正确收到了。

3) 确认丢失和确认迟到

  • 确认丢失 :确认消息在传输过程丢失。当A发送M1消息,B收到后,B向A发送了一个M1确认消息,但却在传输过程中丢失。而A并不知道,在超时计时过后,A重传M1消息,B再次收到该消息后采取以下两点措施:1. 丢弃这个重复的M1消息,不向上层交付。 2. 向A发送确认消息。(不会认为已经发送过了,就不再发送。A能重传,就证明B的确认消息丢失)。
  • 确认迟到 :确认消息在传输过程中迟到。A发送M1消息,B收到并发送确认。在超时时间内没有收到确认消息,A重传M1消息,B仍然收到并继续发送确认消息(B收到了2份M1)。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会,A收到了B第一次发送的对M1的确认消息(A也收到了2份确认消息)。处理如下:1. A收到重复的确认后,直接丢弃。2. B收到重复的M1后,也直接丢弃重复的M1。

连续ARQ协议#

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。接收方一般采用累计确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。

优点: 信道利用率高,容易实现,即使确认丢失,也不必重传。

缺点: 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如:发送方发送了 5条 消息,中间第三条丢失(3号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传一次。这也叫 Go-Back-N(回退 N),表示需要退回来重传已经发送过的 N 个消息。

滑动窗口和流量控制#

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。

拥塞控制#

在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。相反,流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

为了进行拥塞控制,TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。

TCP的拥塞控制采用了四种算法,即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。

  • 慢开始: 慢开始算法的思路是当主机开始发送数据时,如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞,因为现在还不知道网络的符合情况。经验表明,较好的方法是先探测一下,即由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1,每经过一个传播轮次,cwnd加倍。
  • 拥塞避免: 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大,即每经过一个往返时间RTT就把发送放的cwnd加1.
  • 快重传与快恢复: 在 TCP/IP 中,快速重传和恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能快速恢复丢失的数据包。没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。有了 FRR,就不会因为重传时要求的暂停被耽误。  当有单独的数据包丢失时,快速重传和恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作。

URL 到网页显示的过程#

三歪问我:键入网址后,期间发生了什么?

  • HTTP URL
  • DNS 域名解析
  • 传输层 TCP、UDP
  • 网络层 IP、OPSF 路由表
  • 数据链路层 ARP MAC 地址
  • 物理层

ARP#

将 32 为 IP 解析为 48 位 MAC 地址的协议

  • 发 ARP 报文,拿着一个 IP 地址进行广播,问这是谁的 IP
  • 拥有这个 IP 的设备予以回应,并携带自己的 MAC
  • IP ↔ MAC 的映射关系被维护到表中

ARP 攻击

  • 攻击者声称任何 IP 的拥有者都是自己,从而劫持流量

防御

  • 最保险的方式,将 IP ↔ MAC 的关系静态化,提前协商并固定下来

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值