标准互联网通信模型(TCP/IP)

标准互联网通信模型


(一)OSI模型:7层

从下到上依次是:

  1. 物理层:0/1,单位为比特

  2. 链路层:单位为

  3. 网络层:单位为,主要协议有IPv4IPv6ARP,提供点对点通信,主要负责数据包的产生、分发以及路由

  4. 传输层:单位为报文,主要协议有TCPUDP,提供端对端通信(也即进程间通信

    为什么有网络层了还需要传输层?
    (1)网络层的IP协议是不可靠协议,无法像TCP一样保证可靠传输。
    (2)网络层只提供点对点的通信,即将包发到对应的IP,却不知道应该发给哪个端口的具体应用。

  5. 会话层:单位为session

  6. 表示层:设备固有数据格式和网络标准数据格式的转换

  7. 应用层:单位为应用,主要协议有HTTP:80HTTPS:443FTP:21SSH:22……

该模型过于理想化,分层太多,过于复杂,没有被采用,但是对后续的TCP/IP模型有巨大影响。


(二)TCP/IP模型:5层

RFC(Request for Comment)

从下到上依次是:

  1. 物理层
  2. 链路层
  3. 网络层:IPARPICMP
  4. 传输层:TCPUDP
  5. 应用层:HTTP:80DNSURIHTMLTLS/SSLSMTPPOPIMAPMIMETELNETSSH:22FTP:21

网络层协议

  1. IP:将分组数据包发送到目的主机,不具备重发机制,所以数据非可靠传输协议。
  2. ICMP:IP数据包在发送途中一旦发生异常无法到达目标地址,需要给发送端发送一个异常通知,ICMP基于此目标设计,有时也被用于诊断网络健康状态。
  3. ARP从IP地址解析出MAC物理地址。具体做法是,如果机器需要知道某个IP对应的MAC地址,那么就往链路中广播一个带对应IP地址的包,链路上收到这个包的所有机器检查自己的IP是否是包中请求IP,如果是则将自己的MAC地址返回。
  4. NAT(Network Address Translation,网络地址转换):内网IP无法和外网通信,需要在路由器上安装NAT,这样所有内网机器都可以通过这个路由器和外网通信,在外网看来,它们的IP都是路由器VIP

传输层协议

1.TCP

TCP面向连接,是可靠传输协议,可以保证报文正确、有序到达,能够处理传输过程中的丢包、乱序等异常情况,同时还具有拥塞控制机制。
但是为了建立连接,会浪费网络流量,速度

TCP主要通过检验和序列化确认应答重发控制连接管理以及窗口控制等机制来实现可靠性传输。

应用:ping心跳检测


TCP可靠性保障
1.序列号(seq) & 确认应答(ack)

接收方收到发送方发来的数据,要回复一个确认应答(ack),如果发送方超时未收到确认应答,会重新发送
由于网络延迟等原因,可能接收方发送了ack,但是还没有到达发送方就已经超时了,发送方会重新发送,这样就会造成同样的数据在接收方有两份,所以需要给每个数据包一个序列号(seq),如果收到重复的就直接丢弃

2.超时重发

TCP会在每次发包时计算往返时间和偏差,重发时间是比往返时间(RTT)和偏差相加要大一点点的值。
最初的数据包还不知道往返时间,所以其超时重发一般设置为6s左右。
数据被重发之后如果收不到ack,会再次发送,但是等待时间会以2的指数增长
但是数据也不会无限重发,到达阈值后,会判定网络或接收方发生了异常,强制关闭连接

3.连接管理:3次握手,4次挥手
  • 三次握手
  1. SYN=1,seq=x:请求建立连接,置发送序号x
  2. SYN=1,ACK=1,ack=x+1,seq=y:收到了发来的x,请求建立连接,置发送序号y
  3. ACK=1,ack=y+1,seq=z:收到了y,连接建立,置发送序号z

为什么TCP需要三次握手?
因为TCP是全双工的,需要保证双方都能够正常收发数据,建立可靠的通信信道。

  • 四次挥手
  1. 发起方请求断开连接
  2. 接收方收到请求,做出应答
  3. 接收方数据已发送完,请求断开连接
  4. 发起方收到请求,等待2MSL的TIME-WAIT,断开连接

    为什么最后发起方要等待一个2MSL的TIME-WAIT?
    因为如果发起方最后的应答没有被接收方收到,那么接收方就会重发一次FIN,接收方再次应答,最多是2MSL,超过这个时间报文就会在网络中消亡。保证一个2MSL的TIME-WAIT可以保证下一次连接建立时网络中没有上一次的数据包存活

4.流控制 & 窗口大小

接收方主动通知发送方自己可以接收数据的大小,于是发送方不会发送超过这个大小的数据,该大小就是窗口大小,这种模式就是流控制

5.滑动窗口协议 & 回退N协议 & 选择重传

发送方不会在发送完一个报文后就等待ack,而是以窗口为单位,发送完一批报文后,等待全部报文的应答。
回退N协议是指如果这一批报文中有一个没有被正确收到,那么就整个重发这一批的报文。
选择重传则是只选择重发未正确收到的那几个报文。

6.拥塞控制 & 慢启动 & 快速恢复

参考《TCP拥塞控制及BBR原理分析》

拥塞控制中的经典概念:

  • RTT数据包发送到它的ack返回的时间
  • RTO:重传超时,比如RTO = 3 * RTT
  • SACKTCP Option携带多组ACK消息
  • FR(Fast Retransmission):收到3dup ack后,即可认为发生了丢包,不需要等待RTO超时即可重传丢失的包
  • ER(Early Retransmission):无法产生足够的dupack和没有新的数据包可以发送进入网络的情况下,减少触发FRdup ack数量,以达到触发FR的目的
  • Pacing:控制发送速率,防止bursting
  • cwnd:发送窗口,拥塞窗口,在拥塞控制过程中窗口大小会改变
  • rwnd:接收窗口,通知发送者能够发送的数据大小
  • sliding window:滑动窗口
  • 流控:使发送方发包的速度,不超过接收方收包的能力,通过滑动窗口机制实现

拥塞控制中的不公平问题:

  1. 拥塞发生时,面向连接的TCP会按照拥塞步骤进入拥塞避免阶段,但是无连接的UDP不会减少向网络发送的数据量,这就导致了遵守拥塞控制的TCP数据流得到的网络资源越来越少,没有拥塞控制的UDP则得到越来越多的网络资源
  2. TCP连接之间由于使用了不同的拥塞控制算法,也会存在不公平。一些TCP在拥塞前使用了大窗口尺寸,或者它们的RTT较小,或者数据包比其他TCP,这样它们也会占有更多带宽。

拥塞控制过程:

  1. 慢启动
  2. 拥塞避免
  3. 拥塞发生
  4. 快速恢复

拥塞控制算法:

①基于丢包的拥塞控制:Reno

连接建立时cwnd = 1,每收到一个ackcwnd++,呈线性上升;每当过了一个RTTcwnd = cwnd * 2,呈指数上升。cwnd >= ssthresh(slow start threshold)就会进入拥塞避免阶段,将拥塞窗口降到原来的一半,从0开始以指数递增方式重新发送数据

其实“慢启动”并不慢!!!

缺点:

  1. Reno增长慢、减少快,一个数据包丢失造成的窗口缩小需要很长的时间来恢复,带宽利用率不可能很高,而且随着网络带宽不断提升,这种弊端会越来越明显。
  2. 丢包可能不是网络拥塞,而是一种网络常态,但是Reno无法进行区分

    Westwood算法会同步检测RTT,所以可以区分丢包是否是网络拥塞。

②基于时延RTT的带宽预测:Vegas

通过对RTT的监控来计算一个基准RTT,然后通过这个基准RTT来估计当前的网络实际带宽,如果实际带宽比我们的期望的带宽要小或是要多的活,那么就开始线性地减少或增加cwnd的大小。
缺点:当不同的数据流对网络瓶颈带宽进行竞争时,具有较小RTTTCP数据流的拥塞窗口增加速率将会快于具有大RTTTCP数据流,从而将会占有更多的网络带宽资源

③基于丢包和RTTWestwood

Westwood根据RTT变化来判断丢包是否是网络拥塞造成的,还是网络常态的丢包。如果时延变化不明显,就认为是非网络拥塞,此时cwnd减少的比较小。

④二分搜索最佳cwndBIC-TCP

当出现丢包的时候,说明最佳窗口值应该比这个值小,那么BIC就把此时的cwnd设置为max_win,把1/2(max_win + min_win)设置为min_win,然后BIC就开始在这两者之间执行二分思想:每次跳到max_winmin_win的中点。
缺点:RTT小的连接,窗口调整发生的速度越快,因此可能更快的抢占带宽。


TCP报文格式

TCP报文格式

  1. 源端口:16位Source Port

  2. 目的端口:16位Destination Port

  3. 序列号:seq

  4. 确认应答号:ack(一定要ACK置为1才有效

  5. 数据偏移:offset,该字段表示TCP所传输的数据部分应该从那个位开始计算,当然可以把它看作TCP首部的长度

  6. 保留

  7. 控制位(8个)

    ①CWR(Congestion Window Reduced):置为1通知对方已将拥塞窗口缩小
    ②ECE(ECN-Echo):置为1会通知对方网络拥塞
    ③URG(Urgent Flage):置为1表示包中有需要紧急处理的数据;
    ④ACK(Acknowledgement Flag):置为1表示确认ack有效
    ⑤PSH(Push Flag):置为1表示需要将收到的数据立即传给上层应用协议;
    ⑥RST(Reset Flag):置为1表示出现异常必须强制断开
    ⑦SYN(Synchronize Flag):置为1表示希望建立连接
    ⑧FIN(Fin Flag):置为1表示希望断开连接

  8. 窗口大小:不允许发送超过窗口大小的数据

  9. 校验和

  10. 紧急指针:只有在URG=1时有效

  11. 选项

  12. 数据


TCP最大连接数:理论上无限
  1. TCP最大端口数:65535

  2. TCP连接决定因素:【source ip 、 source port】 + 【dest ip 、 dest port】

  3. 也就是说同一个TCP端口(只要目的IP和端口不同)可以接受的连接数理论上是无限的

  4. 但是在Linux中一切都是文件,也就是说“连接”也是文件 —— 每建立一个TCP连接都需要在内存中打开一个文件句柄

    通过ulimit -n命令可以查看limits.conf中配置的允许打开的最大文件数

  5. 总结:Linux中可以建立的TCP连接数理论上是无限的,但是实际上这个数值收到内存大小的限制


2.UDP:User Datagram Protocol

UDP无连接,速度,但是不可靠,不提供任何重发、纠错机制,通常用于让广播和细节控制交给应用的通信传输,比如网络会议、IP电话、DNS等。

UDP报文格式

  1. 源端口:16位Source Port
  2. 目的端口:16位Destination Port
  3. 包长度:首部的长度和数据的长度之和
  4. 校验和
  5. 数据
-------------本文结束感谢您的阅读-------------

本文标题:标准互联网通信模型(TCP/IP)

文章作者:DragonBaby308

发布时间:2019年07月27日 - 20:10

最后更新:2020年02月27日 - 21:43

原始链接:http://www.dragonbaby308.com/tcp-ip/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

急事可以使用右下角的DaoVoice,我绑定了微信会立即回复,否则还是推荐Valine留言喔( ఠൠఠ )ノ
0%