参考模型

一般将TCP/IP分为四层,OSI参考模型分为7层

7 应用层

  • 针对每个应用程序的协议
  • 如电子邮件协议、远程登录协议、文件传输协议ftp、http、DNS、URI、SSH

6 表示层

  • 设备固有数据格式和网络标准数据格式间的转换

5 会话层

  • 通信管理,负责建立和断开通信连接,以及数据分割等处理

4 传输层

  • 负责管理两个节点之间的数据可靠传输(确保数据可靠地传送到目标地址)
  • TCP、UDP协议

3 网络层

  • 主要负责寻址和路由选择
  • IP协议(IPv4IPv6)、ARP、ICMP

2 数据链路层

  • 互联设备之间的传送和数据帧的生成与接收
  • 通过MAC来唯一标识(MAC,物理地址,一个主机会有一个MAC地址)

1 物理层

  • 数字信号和点子信号间的转换

数据发送和接收

每个分层中,都会对所发送的数据附加一个首部,每个包首部中至少会包含两个信息:发送端地址和接收端地址。以太网用MAC地址,网络层用IP地址,TCP/UDP会用端口号。
另外每个分层包首部还包含一个标志位,用来标志上一层协议种类信息

IP协议

IPv4地址由32位数表示,ip地址由网络地址(网络标识)和主机地址(主机标识)两部分组成。网络地址和主机地址的分段以子网掩码区分,子网掩码的主要作用有两个,一是用于屏蔽IP地址的一部分以区别网络标识和主机标识,并说明该IP地址是在局域网上,还是在远程网上。二是用于将一个大的IP网络划分为若干小的子网络。子网掩码可在ip地址后加上/表示,比如172.20.0.0/16或172.20/16
IP地址分类

A类

  • 0开头
  • 区间:0.0.0.0~127.0.0.0
  • 子网掩码:255.0.0.0
  • 私有地址:10.0.0.0~10.255.255.255(10/8)

B类

  • 10开头
  • 区间:128.0.0.0~191.255.0.0
  • 子网掩码:255.255.0.0
  • 私有地址:172.16.0.0~172.31.255.255(172.16/12)

C类

  • 110开头
  • 区间:192.0.0.0~223.255.255.0
  • 子网掩码:255.255.255.0
  • 私有地址:192.168.0.0~192.168.255.255(192.168/16)
  • 每个网段只有254个地址,因为全0表示对应网段或地址不可知,全1表示广播地址

D类

  • 1110开头
  • 区间:224.0.0.0~239.255.255.255
  • 子网掩码:255.255.255.255
  • 多拨地址

E类

  • 区间:240.0.0.0~255.255.255.254
  • 保留地址

广播地址

  • 将主机地址全部设为1,就是广播地址

ARP/RARP协议

  • ARP 是根据IP地址获取MAC地址的一种协议。
    在以太网上发送ip包时,因为链路层需要知道MAC地址,先根据ip地址查一下ARP缓存,如果没有查到,则发送一个ARP协议广播包,这个广播包里面就有待查询的IP地址,而直接收到这份广播的包的所有主机都会查询自己的IP地址,如果收到广播包的某一个主机发现自己符合条件,那么就准备好一个包含自己的MAC地址的ARP包传送给发送ARP广播的主机。广播主机拿到ARP包后会更新自己的ARP缓存。

只适用于ipv4,ipv6中用ICMPv6代替。

  • RARP 是从MAC地址定位ip地址的一种协议。
  • arp 命令

ICMP协议

ICMP的主要功能包括,确认IP包是否成功到达目标地址,通知发送过程中ip包被弃用的原因,改善网络设置等。当传送IP数据包发生错误,比如主机不可达,路由不可达等等,ICMP协议将会把错误信息封包,然后传送回给主机。
常用命令

  • ping
  • traceroute

NAT

NAT用于在局域网中使用私有地址,在链接互联网时使用全局ip地址,除ip地址转换外,还有可以转换TCP、UDP端口号的NAPT技术。
缺点:不能从NAT外部向内部服务器建立连接

TCP/UDP

TCP连接的建立与终止

三次握手

  • 第一次握手:建立连接。客户端发送连接请求报文段,将SYN位置为1,Sequence Number为x;然后,客户端进入SYN_SEND状态,等待服务器的确认;
  • 第二次握手:服务器收到SYN报文段。服务器收到客户端的SYN报文段,需要对这个SYN报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);同时,自己自己还要发送SYN请求信息,将SYN位置为1,Sequence Number为Y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中,一并发送给客户端,此时服务器进入SYN_RECV状态;
  • 第三次握手:客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED状态,完成TCP三次握手。

为什么要三次握手?两报文握手可以吗?
为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。

具体例子:“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。

于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”

四次分手

  • 第一次分手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;
  • 第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;
  • 第三次分手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;
  • 第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。

为什么要四次分手?
TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式,这就意味着,当主机1发出FIN报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。
为什么要等待2MSL

MSL:报文段最大生存时间,它是任何报文段被丢弃前在网络内的最长时间。

  • 保证TCP协议的全双工连接能够可靠关闭
  • 保证这次连接的重复数据段从网络中消失
    第一点:如果主机1直接CLOSED了,那么由于IP协议的不可靠性或者是其它网络原因,导致主机2没有收到主机1最后回复的ACK。那么主机2就会在超时之后继续发送FIN,此时由于主机1已经CLOSED了,就找不到与重发的FIN对应的连接。所以,主机1不是直接进入CLOSED,而是要保持TIME_WAIT,当再次收到FIN的时候,能够保证对方收到ACK,最后正确的关闭连接。

第二点:如果主机1直接CLOSED,然后又再向主机2发起一个新连接,我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题,但是还是有特殊情况出现:假设新连接和已经关闭的老连接端口号是一样的,如果前一次连接的某些数据仍然滞留在网络中,这些延迟数据在建立新连接之后才到达主机2,由于新连接和老连接的端口号是一样的,TCP协议就认为那个延迟的数据是属于新连接的,这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL,这样可以保证本次连接的所有数据都从网络中消失。

窗口控制

如果每发一个段都进行一次确认应答会很慢,于是引入窗口概念,发松端无需等待确认应答而是继续发送,窗口大小就是指无需等待确认应答的可以继续发送数据的最大值。
确认应答丢失不会重发;报文段丢失,发松端连续3次收到收到同一个确认应答就会进行重发。

流量控制

如果发送方把数据发送得过快,接收方可能会来不及接收,这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收。
TCP首部中,有一个字段用来通知窗口大小。利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
接收端的缓冲区一旦面临数据溢出时,窗口大的值就会设置为一个更小的值通知给发松端,发松端就会根据接收端的指示,进行流量控制。

拥塞控制


发送方维持一个拥塞窗口 cwnd ( congestion window )的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去。但只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络中的分组数。

  1. 当 cwnd < ssthresh 时,使用上述的慢开始算法。
  2. 当 cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
  3. 当 cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法。
  • 慢开始
    通常在刚刚开始发送报文段时,先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后,把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ,可以使分组注入到网络的速率更加合理。
  • 拥塞避免
    拥塞窗口cwnd缓慢地增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍。
  • 快重传
    快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)而不要等到自己发送数据时才进行捎带确认。

快重传算法还规定,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待未收到的报文段设置的重传计时器到期。

  • 快恢复
    与快重传配合使用的还有快恢复算法

当发送方连续收到三个重复确认,就执行“乘法减小”算法,把慢开始门限ssthresh减半。

参考

https://juejin.cn/post/6844903490595061767
https://www.ihewro.com/archives/913/
https://mp.weixin.qq.com/s/VMz2bDV5JZo0YH5fRQ9mSw

最后修改:2021 年 08 月 26 日 03 : 47 PM