tcp/ip详解

个人感觉tcp协议有种弥补ip协议的不足。

ip协议是一个无状态、无连接、不可靠的服务。
当接受端分用数据时, 它提交给上层协议时,这些数据可能是乱序的、重复的。
他不会处理这些数据。 因此需要我们上层的传输层TCP协议来进行处理,处理完毕之后递交给应用层。

说说IP协议的优点:

1、由于无状态, 内核不需要开辟资源维护双方通信信息,简单、高效, 这点和UDP、HTTP协议相同。
2、由于无状态, IP通信双方不会长时间维护对方IP地址信息, 每次发送数据时,都需要指定对端的IP地址。
3、不可靠, IP协议不保证数据能够到达对端,存在丢包问题。(比如某个中转路由丢包了,会给发送端返回一个ICMP【超时错误】,或者是接受段发现IP数据包不正确,将其丢弃,并返回ICMP【IP头部参数错误】), 当丢包了会通过发送ICMP通知上层协议发送失败, 但是在IP协议这层不会重传。

如果想要实现数据确认、重传等机制我们需要搭配TCP协议使用。
当然如果是UDP的话, 我们需要在应用层协议设置这些机制。

那么IP协议这一层有什么用呢?

1、IP分片
这是网络层到数据链路层之间的关系。当IP数据报长度超过数据链路层的以太帧MTU(1500字节), IP协议会将这个数据分片传输。

对于TCP协议封装的数据报不需要分片, 因为TCP每次传输数据不超过MSS(最大报文长度)
MTU = MSS + IP报头 + TCP报头。

1500字节 = IP头部(20字节) + 数据(1480)
当然1480数据 = UDP(20字节) + 原始数据(1460,包含应用层协议)

对于IP协议这一层我们我将上层协议的封装看成一个整体。除IP20字节,也就是1480的最大传输量。

当数据量为1501(包含IP)时, 会存在分片,分两片。
1片: 1500字节。
2片: 21字节。

2、IP路由选择
IP协议的核心任务就是数据报的路由, 决定发送数据报到目标机器的路径。
IP路由过程 = 发送到哪个路由 + 经过哪个网卡发送。

在IPv4头部信息中包含一个8位生存时间(TTL), 我们把它称为跳数。 每经过一个路由TTL-1, 如果TTL为0, 路由器会把数据丢弃,并向源端发送一个ICMP【差错报文】

TTL的功能:防止路由循环, 占用路由资源。

关于ICMP协议, 它是网络层协议, 通过ping应用程序可以使用它。
ICMP分为两大类。
1、差错报文: 这类报文主要回应网络错误。
2、查询报文: 这类报文主要查询网络信息(比如使用ping)
3、网络重定向

TCP协议详解

TCP协议时TCP/IP协议中另一个重要的协议,相对于IP协议,它更靠近应用层协议, 因此具有更强的操作性。

一、TCP服务的特点
TCP:面向连接、 流传输、 可靠传输
UCP:不面向连接、 数据报传输、 不可靠传输

基于上述的特点: TCP通信双方会建立连接, 会在内核中开辟一些资源来维护双方的通信(接发方缓冲区), TCP是全双方通信, TCP连接是点对点的。
在通信完毕之后, 需要断开连接, 释放内核维护的资源。

UDP则不需要。

对于TCP: 发送端执行的写操作次数和接受端执行读操作次数之间没有数量关系, 这就是字节流的概念, 并且应用程序对数据的发送和接收是没有边界限制的。
也就是我可以每次读取一点点, 多次去读, 或者一次性读取完都可以。

对于UDP: 应用程序需要及时针对每一个UDP数据报进行读操作。 否则就会丢包。 其次应用程序需要指定足够的缓冲区来读取UDP数据,否则UDP数据将会被截断。

二、TCP可靠传输的原理&流量控制

1、确认应答机制
在发送端发送数据包之后,接受段会返回发送端ACK确认包。

2、超时重传机制
发送端发送数据包之后, 如果在RTO时间段内没有收到对应的确认包,就会重传这个数据包, 保证可靠传输.

3、包序管理
在发送端发送的数据包,是一段一段的、是有序的。 接受段在收到这些数据包之后,会将这些数据包排序,然后返回给我们用户。

4、滑动窗口
在滑动窗口中有两种类型的数据, 一种是发送了但是没有收到对应的ACK确认包,另外一种就是准备可以发送了, 当发送的数据包收到了确认包之后,就会移出滑动窗口。

1)在滑动窗口中数据包都是有序的。
如果发送数据包序列为1,2,3,4,5, 如果2号数据包丢包了。 接受段收到了1、3、4、5数据包,收到了1号数据包返回1号确认包, 收到了3,4,5数据包不会返回3,4,5确认包, 会返回1号重复数据包。 这时候我们发送端收到了重复的确认包,然后立刻重传2号数据包。

2)滑动窗口的流量限制
接受段返回ACK确认包中win窗口大小会限制发送端发送窗口的大小。从而达到流量限制。

零窗口探测计时器-持续定时器:
如果接受段ACK确认包中win窗口大小为0,代表着接受段接受缓冲区满了, 通知发送端不要发送数据了。这会装不下, 当应用程序把接收缓冲区的数据读以后,有剩余空间, 接受端会发送一个ACK, 通过ACK里面的win窗口大小来告知发送端可以发送数据了。

如果没有持续计时器,就会存在一个问题。
当接收端在再发送ACK告知发送端可以发送数据时, 这个ACK数据包丢包了。
这个时候,发送端由于没有收到通知, 一直处于等待接收端通知, 而接收端认为我已经通知了, 自己现在等待发送端发送数据。 这个时候,双方都会处于等待,不会发送数据,处于死锁。

因此诞生了持续计时器。
当发送端收到win为0时, 就会启动一个计时器。如果再时间内没有收到win>0的ACK通知, 发送端会主动发送一个探测包, 强迫接收端告诉自己的状态。

5、拥塞窗口
拥塞窗口它是考虑整个网络的情况。(包括路由、硬件电气设备等因素)

1、慢开始算法
拥塞窗口每经过一个轮次,以指数的形式上升 (2^n)

2、拥塞避免算法
拥塞窗口每经过一个轮次, 线性上升(n)

3、慢开始门限(ssthresh)
当拥塞窗口小于 ssthresh 时, 窗口大小调用慢开始算法, 当大于 ssthresh,调用拥塞避免算法

4、慢启动
一开始拥塞窗口设置为1, 没经过一个轮次,窗口依据慢开始算法和拥塞避免算法提升。

判断网络拥塞的情况:
在这里插入图片描述

如果在此期间遇到网络拥塞(丢包), 会设置ssthresh门限为拥塞窗口的一半。然后将拥塞窗口设置为1, 然后调用慢开始算法。

一开始窗口不会设置为很大,因为要需要考虑网络问题,如果网络拥塞, 这时候发送大量的数据包只会造成网络问题更加严重。
刚好一开始设置的很小, 也可以探测网络情况, 当出现网络拥塞,窗口大小也可以做调整。

5、快重传
当接收端连续收到3次重复的确认包, 这个时候会立刻重传丢失的数据包,不需要等待超时重传机制。
在这里插入图片描述
例如上图:M3数据包丢包, M4,M5,M6的确认包返回的时M2。 代表着M3数据包丢包了。

6、快恢复
将ssthresh设置为拥塞窗口的一半, 然后拥塞窗口在ssthresh基础上调用拥塞避免算法。

当快重传之后,就会调用快恢复,这两个搭配使用。

在这里插入图片描述

在旧的版本Tahoe, 当调用快重传之后, 它的处理方式是将ssthresh设置为cwnd的一半, 然后将cwnd设置为1, 调用慢开始算法。

新版本Reno, 快重传之后, 它的处理方式是将ssthresh设置为cwnd的一半, 然后调用拥塞避免算法。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值