TCP/IP体系结构
TCP/IP四层协议 | 五层协议 | 协议 | 作用 |
---|---|---|---|
应用层 | 应用层 | HTTP超文本传输协议、FTP文件传输协议 | - |
运输层 | 运输层 | TCP(面向连接的,可靠的)、UDP(无连接的,不保证数据传输可靠性) | 两台主机的进程之间提供通用的数据传输服务 |
网际层 | 网络层 | IP | 控制子网的运行,逻辑分址、分组传输、路由选择等 |
网络接口层 | 数据链路层 | - | 物理寻址,同时将比特流转变为逻辑传输线路 |
网络接口层 | 物理层 | - | 不同物理介质字节流的传输 |
运输层
一、TCP连接管理:建立(三次握手)、释放(四次握手)
1 TCP连接建立过程(三次握手)
- SYN=1;seq=x;
- SYN=1、ACK=1;ack=x+1;seq=y;
- ACK=1;seq=x+1;ack=y+1;
2 三次握手的作用
第一次握手:服务端确认发送方发到了。(即服务端确认客户端发送正常、服务端接收正常。)
第二次握手:客户端确认客户端发到了,服务端发到了。(即客户端确认客户端发送、接收正常,服务端发送、接收正常。)
第三次握手:服务端确认接收方发到了。(即服务端确认客户端接收正常、服务端发送正常。)
至此,两方都确认了两方发送、接收正常。
并且,第三次握手防止服务端收到的是客户端之前由于网络等问题造成的已失效连接请求,若此时就确认连接建立,则一直等待客户端继续发送报文,造成服务端一直等待,浪费服务端连接资源的问题。
3 TCP报文段的首部格式
TCP是面向字节流的。TCP传送的数据单元是报文段,报文段首部前20个字节是固定的(首部20~60字节)。
- 源端口、目的端口(2字节+2字节)
- seq:序号。客户端有自己的一组,每次递增1,服务端有自己的一组,每次递增1。(4字节)
- ack:当确认号=seq+1,表示到seq为止的所有数据都已经正确收到。(4字节)
-
- 同步位SYN:当SYN=1,ACK=0,表示这是一个请求报文。
- 确认位ACK:
- 紧急位URG:URG=1时,表明紧急指针字段有效,配合紧急指针字段使用。表明此报文段中有紧急数据应尽快传送,发送方会根据紧急指针把紧急数据插入到本报文段数据的最前面。
- 终止为FIN:表明此报文段的发送方已发送完毕,要求释放连接。
- 选择确认位SACK:此外置1,则可在可选项表明收到的数据的边界,不用把第一个丢失未收到的数据后面的都要重传了。由于头部空间的限制,SACK使用较少。
- 数据偏移:表明TCP报文段数据起始处距TCP报文的起始处有多远。
- 窗口值:本方接收窗口大小。告诉对方:从报文段首部的确认号算起,本方的接收窗口允许对方发送的数据量是多少字节。(2字节)
-
- 检验和:检验和字段检查的范围包括首部和数据这两部分。(2字节)
- 紧急指针:指出了本报文段中紧急数据的字节数(紧急数据结束后就是普通数据)。(2字节)
- 选项(可选,0~40字节):
- 最大报文长度MMS选项:即数据字段的最大长度,把自己能够支持的MSS值写入这一字段,以后就按照这个数值传送数据。若主机未填写这一项,则MSS的默认值是536字节长,因此,因特网所有主机都应能接受的报文段长度是536+20(固定首部长度)=556字节。
- 窗口扩大选项:用于之前的窗口字段不够用的情况。
- 时间戳选项:计算往返时间RTT。发送方把当前时间放入时间戳字段,接收方确认该报文段时把时间戳字段复制到时间戳回送回答字段。因此,在发送方收到确认报文时,可以计算出RTT。
- 填充(使发送的报文头部是4个字节的整数倍)
4 TCP连接释放过程(四次挥手)
- TCP两个方向的连接释放可以分开进行,可以是一方主动关闭、一方被动关闭,也可以是两方同时主动关闭。释放一个方向时称TCP连接处于半关闭状态。
- 两次握手后,A进入终止等待2状态,等待B发出连接释放报文段。
- 四次握手后,TCP连接没有立即释放掉,A必须经过时间等待计时器设置的时间后,才能进入关闭状态。
- 四次握手后发送方不立即关闭作用1:第四次握手A发送的确认报文B可能没收到,B会重发释放请求,A在等待时间内等待看是否有这种情况,是的话重发第四次握手。
- 作用2:经过时间等待计时器的时间,A可以使本连接所有产生的报文段都从网络中消失,防止下一个新的连接中出现本次连接旧的失效的报文段。
- 为什么建立连接是三次握手,而关闭连接却是四次挥手
可以进行单向的连接释放,也就是关闭A向B的连接,B可以将未发送完的数据继续发送给A,发送完再释放B向A的连接。
二、TCP可靠传输
1 可靠传输的工作原理:自动重传请求ARQ(指重传的请求是自动进行的,接收方不需要请求发送方重传某个出错的分组)
停止等待(TCP协议未使用,为了讲述概念)
停止等待:每发送完一个分组就停止发送,等待对方确认。在收到确认后再发送下一个分组。
发送方:丢失/差错:在超时计时器时间后还没收到确认信息就超时重传;重复确认报文:忽略。
接收方:丢失/差错:接收方丢弃报文不发送确认报文;重复报文:丢弃重复发送的报文,并再次发送确认。
连续ARQ协议(TCP协议使用的)
采用滑动窗口机制:
- 发送方维持发送窗口:表示位于发送窗口内的5个窗口都可以连续发送出去,而不需要等待对方确认。提高信道利用率
- 接收方采用累积确认的方式:只需对按序到达的最后一个分组发送确认,表示到这个分组为止的所有分组都已经正确收到。
- 若发送方发送了前5个分组,中间的第三个分组丢失,则发送方需要把后三个都重传,叫做回退N。所以通信线路质量不好时,连续ARQ协议会带来负面影响。
2 可靠传输的实现
滑动窗口
- TCP的滑动窗口以字节为单位的。
- 发送窗口:大小=接收报文指定的窗口值,发送窗口内后沿为确认号对应的数据,发送窗口内是可以发送的数据,并且不能丢弃。(包含已发送但未收到确认的数据+允许发送但尚未发送的数据)。
- 接收窗口:窗口内是待接收的数据;
- 当发送方的发送窗口都是已发送但未收到确认的数据时,经过超时计时器时间,则超时重传,直到收到落在窗口内的确认,保证可靠传输。
- 发送缓存包含发送窗口,接收缓存包含接收窗口。
超时重传时间RTO的选择
RTO 略大于 加权平均往返时间RTTS
选择确认SACK
此外置1,则可在可选项表明收到的数据的边界,不用把第一个丢失未收到的数据后面的都要重传了。由于头部空间的限制,SACK使用较少。
三、TCP的流量控制(点对点通信量的控制)
- 流量控制:让发送方的发送速率不要太快,要让接收方来得及接收。
- 滑动窗口实现流量控制:接收方通过确认报文给出的接收窗口大小控制发送流量。
- 解决0窗口通知后的窗口变大的报文丢失造成的双方互相等待的死锁问题:收到0窗口通知的一方,设有持续计数器,时间到了就发一个仅带1窗口长度的探测报文,对方就会重新发带有窗口大小的探测报文。
四、TCP的拥塞控制(对整个网络)
拥塞和拥塞控制
拥塞:网络中资源供不应求。表现为:吞吐量随负载(单位时间输入给网络的分组数目)增多,网络吞吐量的增长速率逐渐减小,甚至下降,此时网络就进入了拥塞状态。
拥塞控制:防止过多数据注入到网络中,使网络中的路由器或链路不致过载
拥塞控制方法(一直注意TCP窗口单位为字节)
1 慢开始算法+拥塞避免算法:AIMD算法(加法增大乘法减小算法) 使用广泛
慢开始算法
- 发送方维持一个拥塞窗口(cwnd),发送方让自己的发送窗口为拥塞窗口和对方接收窗口的较小值。
- 拥塞窗口的大小取决于网络的拥塞程度,发送方如何知道网络发生了拥塞?没有按时收到确认报文。因为网络发生拥塞时,路由器会丢弃分组。
- 拥塞窗口初始为1个最大报文段MSS的数值,每收到一个新的(报文段)的确认,拥塞窗口+1,故每经过一个传输轮次,拥塞窗口就加倍,即拥塞窗口指数规律增大。
拥塞避免算法
每经过一个往返时间RTT就把发送方的拥塞窗口+1。
AIMD算法(慢开始+拥塞避免)
先慢开始;当达到慢开始门限ssthresh,则变为拥塞避免算法;当出现网络超时,拥塞窗口重置为1,执行慢开始算法,并把慢开始门限变为出现超时时拥塞窗口大小的一半。
2 快重传和快恢复
快重传
发送方只要收到三个重复确认,就立即重传接收方未收到的报文段,而不必等待超时重传计时结束。
要求接收方每收到一个失序报文就立即发出重复确认。
快恢复算法(与快重传配合使用)
当发送发连续收到三个重复确认,就将拥塞窗口变为当前的1/2,并继续拥塞避免算法。(而无需等到网络超时,也不是变为慢开始算法。)
五、UDP
特点
无连接的:发送数据前不需要建立连接。
尽最大努力交付:不提供可靠交付。
面向报文的:UDP对应用层交下来的报文,既不合并也不拆分,一次交付一个完整的报文。
UDP首部字段(8字节)
源端口(2字节)
目的端口(2字节)
长度:UDP数据报的长度(2字节)
检验和:检测UDP数据报在传输中是否有错,有错就丢弃(2字节)
应用层
从浏览器输入URL到页面加载的过程。
- DNS解析
- TCP连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 浏览器解析渲染页面
- 连接结束
相关
http默认端口:80
https默认端口:443