网站建设维护的方案,网站做微信公众号,wordpress自动保存外链mp3,怎样做一个网络营销目录
传输层
传输层功能
传输层所提供的服务
传输层的两个协议
TCP协议与UDP协议
端口
端口分类
IP地址和端口的关系
UDP协议
前言#xff1a;
UDP报文格式
检验和的伪首部
伪首部内容
TCP协议
TCP报文格式
TCP协议数据段的理解
TCP的伪首部
伪首部内容
标…目录
传输层
传输层功能
传输层所提供的服务
传输层的两个协议
TCP协议与UDP协议
端口
端口分类
IP地址和端口的关系
UDP协议
前言
UDP报文格式
检验和的伪首部
伪首部内容
TCP协议
TCP报文格式
TCP协议数据段的理解
TCP的伪首部
伪首部内容
标志位flags
理解TCP的序号与确认号
TCP的几个要点
TCP可靠传输
停止等待-ARQautomatic repeat-request自动重传请求
连续ARQ协议滑动窗口协议
具体案例
SACK选择性确认
传输层数据分段
流量控制
原理
具体案例
流量控制的特殊情况
拥塞控制
前言
拥塞控制方法
基本知识
拥塞窗口、接收窗口、发送窗口的理解
拥塞控制-慢开始
拥塞避免
拥塞控制-快重传
快恢复
TCP连接管理
TCP建立连接三次握手
TCP建立连接三次握手的原因
连接过程以http的get请求为例——数据部分为4字节
TCP释放连接四次挥手
为什么释放连接需要四次挥手
客户端发送ACK报文后需要时间等待原因
时间等待的确认 传输层
传输层功能
定义应用层协议数据报文的端口号流量控制对原始数据进行分段处理
传输层所提供的服务
传输连接服务主要是针对会话层的要求对每一个传输连接去建立相应的连接数据传输服务流量控制差错控制序列控制
传输层的两个协议
TCPTransmission Control Protocol传输控制协议UDPUser Datagram Protocol用户数据报协议
TCP协议与UDP协议 端口
含义应用程序在计算机中的唯一标识
端口分类
源端口一般位于客户机目标端口一般位于服务器
IP地址和端口的关系 注意
端口可分为虚拟端口和物理端口其中虚拟端口指的是计算机内部或交换机路由器内的端口不可见。UDP/TCP首部中端口占用2字节因此可以计算出端口范围0-65535防火墙可以设置开启和关闭某些端口来提高安全性
UDP协议
前言
UDP协议是面向无连接的他减少了建立和释放连接的开销UDP尽最大能力交付不保证可靠传输UDP不需要维护一些复杂的参数首部只有8个字节UDP协议不需要建立连接直接发送数据不会去重新排序不需要确认
UDP报文格式 注意
16位UDP长度指的是UDP首部的长度和UDP数据的总长度16位UDP检验和将伪首部和首部和数据部分计算出一个值用来检测UDP用户数据在传输过程中是否有错有错就丢弃伪首部仅在计算检验和的时候起作用并不会传递给网络层
检验和的伪首部 伪首部内容
源IP地址目标IP地址保留位固定为0协议类型封装所用的协议的数字表示形式UDP长度不包括伪首部长度主要为UDP首部和数据部分的总长度
注意
伪首部固定12个字节伪首部仅在计算检验和的时候起作用并不会传递给网络层
TCP协议
前言该协议要求数据在传输前必须建立连接数据在传输完成后必须释放连接。
TCP报文格式 TCP协议数据段的理解
序号占32位传输过程中的每一个字节都有一个编号在建立连接后序号代表这一次传给对方多个数据包每个数据包的起始位置所在字节的编号。确认号占32位标志位flags内的ACK为1时才有意义代表期望对方下一次传过来的TCP数据部分的第一个字节编号序号数据偏移占4位数据偏移×4为首部的长度由此可以算出TCP首部最长60字节因为首部长度最小20字节所以数据偏移最小为5保留占6位目前全为0标志位flags占6位主要用于分析控制数据段的状态窗口占16位主要用于TCP的流量控制用以告知对方下一次允许发送数据的大小真正的接收缓存区大小还需要乘窗口缩放系数检验和占16位通过伪首部首部数据来计算出检验和用来检测TCP数据段在传输过程中是否有错有错就丢弃紧急指针占16位标志位flags内的URG为1时才有意义若紧急指针为8则代表TCP数据部分前8字节为紧急数据
TCP的伪首部
前言占用12个字节仅在计算检验时起作用并不会传输到网络层 伪首部内容
源IP地址目标IP地址保留位固定为0协议类型封装所用的协议的数字表示形式TCP长度不包括伪首部长度主要为TCP首部和数据部分的总长度
注意
TCP首部中仅仅有4个字段数据偏移记录了TCP报文的首部长度并没有字段记录了TCP报文的数据长度但是伪首部中有TCP首部和数据的总长度TCP长度TCP/UDP的数据长度完全可以由IP数据包的首部推测出来传输层的数据总长度网络层的总长度-网络层的首部长度-传输层的首部长度
标志位flags
UGR紧急指针ACK确认响应序号有效确认建立连接PSH数据传输标记RST重置连接当RST1时表明连接出现问题必须释放连接后重新建立连接SYNSYN1ACK0代表这是一个建立连接的请求FIN发送端完成发送任务要求释放连接
注意flags的设置通过设置0/1来实现
理解TCP的序号与确认号 TCP的几个要点
可靠传输流量控制拥塞控制连接管理
TCP可靠传输
可靠传输客户端发起请求给服务器服务器收到请求给客户端返回数据若服务器返回的数据比较大那么服务器不可能一次性把数据传出去此时数据就会被分成好几个段来进行发送若发送的过程中某个数据包丢失客户端没有确认收到那么服务器只会将该包重新发送
停止等待-ARQautomatic repeat-request自动重传请求
例子A发送3个包给BM1、M2、M3 正常情况A发送M1到BB收到后发确认请求到AA收到确认后发送M2到B以此类推超时情况A发送M1到BM1在运输过程出现差错B丢弃有差错的报文不向A响应确认超时后A重新发送M1给BB收到完好的M1后向A响应确认确认丢失A发起M1向BB收到后向A响应确认M1传输过程确认失效A超时仍没有收到确认再向B重新发送M1B收到后丢弃重复的M1重新向A响应确认A收到确认响应确认迟到A发送M1给BB收到后响应确认到A因为响应超时A向B重传M1B收到后丢弃重复的M1后响应确认到A此时A收到确认可以继续发送其他数据包过一会B的确认到达A不会做任何动作
连续ARQ协议滑动窗口协议 注意
滑动窗口的大小由接收方B决定有些系统重传5次还未成功就会发送RST报文断开TCP连接接受方在拿到发送方发送方的数据的时候首先会放到缓存有大小限制内若缓存将要不够用那么就会告诉发送方特定的接收窗口大小接收窗口大小不是固定死的
具体案例
电脑A向电脑B发送的数据 发送的过程 SACK选择性确认
前言在TCP通信过程中若发送序列中间某个数据包丢失比如1、2、3、4、5中的3在发送过程中丢失了不用SACK技术的话TCP会通过重传最后确认的分组后续的分组最后确认的2会重传3、4、5这样原先已经正确发送的分组也可能重复发送比如4、5降低了TCP的性能为了改善上述情况发展了SACK技术它可以告诉发送方那些数据丢失那些数据已经提前收到这样TCP只重新发送丢失的包3不用发送后续的包4、5 举例 理解假设发送方发了201-1000这么多数据接收方仅仅接受了棕色范围内的数据白色范围内的数据都没接收那么就会告诉发送端自己接受了左边界301右边界401、左边界501右边界601、左边界701右边界801、左边界901右边界1001的数据。
注意
SACK信息会放在TCP首部的选项部分kind占1字节值为5就代表这是SACK选项就意味着TCP选项有很多种length占1字节表明SACK选项共占多少字节left edge占4字节左边界right edge占4字节右边界因为选项部分最多40个字节40字节仅有2字节是刚需留给左右边界的仅有38字节因为左右边界一组为8字节那么仅能存放4组左右边界TCP数据偏移计算得知TCP首部最长60字节有20字节的固定长度所以选项部分最长40字节
传输层数据分段 为什么选择在传输层就进行数据分段而不是等到网络层再分片传递给数据链路层 因为可靠传输是在传输层进行控制的若在传输层不分段那么一旦出现数据丢失那么整个传输层的数据都得重传若在传输层分了段那么一旦出现数据丢失只需要重传丢失的那些段即可。 流量控制
前言接受方在拿到发送方发送方的数据的时候首先会放到缓存若接收方的缓存满了发送方还在疯狂的发送数据那么接收方只能把收到的数据包丢掉大量的丢包会极大的浪费网络资源所以要进行流量控制
含义让发送方发送的速率不要太快让接收方来得及接收处理
原理
通过确认报文中的窗口字段来控制发送方的发送速率发送方发送的窗口大小不能超过接收方给出的窗口大小当发送方收到接收窗口大小为0时发送方就会停止发送数据
具体案例 流量控制的特殊情况 起初接收方给发送方发送了0窗口的报文段后面接收方又有了一些储存空间给发送方发送了非0窗口的报文段丢失了发送方的发送窗口一直为0双方陷入僵局 解决办法当发送方收到0窗口通知时发送方停止发送报文并且同时开启一个定时器隔一段时间就发送个测试报文去询问接收方最新的窗口大小若接收窗口大小还是0则发送方再次刷新启动定时器 拥塞控制
前言 理解
防止过多的数据注入到网络避免网络中的路由器或链路过载
注意拥塞控制是一个全局性的过程涉及到所有主机、路由器以及降低网络传输性能有关的所有因素是大家共同努力的结果相比而言流量控制是点对点的通信控制
拥塞控制方法
慢开始slow start拥塞避免congestion avoidance快速重传fast retransmit快速恢复fast recovery
基本知识
MSSMAXimum Segment Size每个段最大数据部分大小建立连接时确定发送方的每个段都不能超过该值cwndcongestion window拥塞窗口使整个网络恰好拥塞的最小窗口rwndreceive window接收窗口接收方告诉发送方最多发送的数据是多少swndsend window发送窗口实际发送数据的窗口
拥塞窗口、接收窗口、发送窗口的理解 假设接收方窗口大小为3000那么发送方的发送窗口发送的数据最多为3000而拥塞窗口是会经常变动的假设网络现在繁忙不能发送太多拥塞窗口只有2000没有超过接收窗口的3000那么发送窗口和拥塞窗口都是相等的若现在网络很顺畅拥塞窗口有5000而对方接收窗口为3000那么接收窗口等于发送窗口。 总结发送窗口min接收窗口拥塞窗口 拥塞控制-慢开始 理解接收方告诉发送方让发送方最多发送3000数据每个包的数据部分不能超过100接收方收到请求首先先发1个包然后收到对方的确认了然后发送方明白了发送一个包没问题网络不堵可以再给加点量然后发送方发了2个包对方又都确认了那再发4个对方都确认那么再发8个。
拥塞窗口随时间变化关系图 总结cwnd拥塞窗口的初始值比较小然后随着数据包被接收方确认收到一个ACKcwnd就会成倍增长指数级增加
拥塞避免 注意
ssthresh(slow start threshold)慢开始阈值cwnd达到阈值后以线性方式增加拥塞避免加法增大拥塞窗口缓慢增大以防止网络过早出现拥塞判断网络拥塞发送方发送的数据没有收到对方的确认那么就考虑重传有些包丢了就可以说明网络可能出现拥塞乘法减小当发送方感知到网络可能拥塞了就把ssthresh减为峰值的一半与此同时执行慢开始算法cwnd又恢复到初始值
拥塞控制-快重传 理解
接收方每当收到一个失序的分组后就立即发出重复确认使发送方及时知道有分组没有到达而不是等待自己发送数据时才进行确认发送方只要连续收到三个重复确认总共4个相同的确认就应当立即重传对方尚未收到的报文段而不必继续等待重传计时器到期后再重传
快恢复 理解当发送方连续收到三个重复确认就执行“乘法减小”算法把ssthresh为减为峰值的一半与慢开始不同的是现在不执行慢开始算法即cwnd现在不会恢复到初始值而是把cwnd值设为ssthresh减半后的数值然后开始执行拥塞避免算法加法增大使拥塞窗口缓慢线性的增大
TCP连接管理
注意连接管理中建立连接的三次握手以及四次挥手的报文中只有TCP报文头部而没有TCP报文数据部分
TCP建立连接三次握手 理解
客户机向服务器发送请求建立连接控制位syn1ACK没有等于1说明这是一个请求建立连接这时会自动生成一个序号seq这个序号是随机的 这个序号我们用x来表示向服务器发起请求服务器收到请求后他会向客户机发送确认请求进而SYN1ACK1同时有了确认的序列号ackx1期望发送原来序列号的下一个请求这时服务端随机生成一个序列号seqy客户机收到服务器发来的确认客户机进行确认ACK1客户机不会再发请求了因此没有SYN同时有了确认序号acky1期望服务器执行下一步操作seqx1开始进行数据传输
TCP建立连接三次握手的原因
若建立连接只需要两次握手那么可能出现客户端发送的第一个请求因为网络延时在连接释放以后的某个时间才到达服务端服务端收到该请求后响应了这个迟到的连接请求但是刚刚客户端已经接受了数据进而不会发起http请求这样服务器就会一直等待进而浪费了资源一直处于建立连接状态
注意若第三次握手失败了此时server的状态为syn-rcvd若等不到客户端的ACKserver会重新发送SYNACK包若此时server多次重发SYNACK都等不到客户端的ACK就会发送RST包强制关闭连接
连接过程以http的get请求为例——数据部分为4字节
注意这里使用的seq和ack都是相对的
1.首先客户端开始发起http的get请求seq为1相对于之前建立连接的xack为1相对于之前建立连接的y含义为期望服务端开始发送数据 2.然后服务器收到请求连续发送4个包之前的连续arq协议 这里面的seq就是发送的每个数据包的起始字节序号这里的ack就是希望客户端开始发送第k1个字节
3.客户端收到对方的4个TCP数据段TCP数据部分占0字节seq标识这是发给服务端的k1个字节ack标识期望服务端发送b1b2b3b41个字节 TCP释放连接四次挥手
前言
TCP是全双工通信TCP/IP协议栈上允许任何一方发起断开连接请求理解
数据传输完成后客户机向服务器发送释放连接请求FIN1同时随机生成序列号u服务端收到客户端的请求进行确认ACK1随机生成序列号seqv此时服务器这边若也觉得没有东西可以发给客户端服务器也会发释放连接请求给客户端FIN1随机生成序列号w客户端收到服务端的请求对其进行确认ACK1告诉服务器知道没有东西发给自己了进而双方关闭连接
为什么释放连接需要四次挥手
第一次挥手当客户端发出FIN报文时表示客户端告诉服务器自己已经没有数据要发送了但是还是可以接收到服务器的数据第二次挥手当服务器返回ACK报文时表示服务器已经知道客户端没有数据要发送了但是服务器还是可以发送数据到客户端第三次挥手当服务器也发送FIN报文时表示服务器告诉客户端服务器也没有数据要发送了第四次挥手当客户端返回ACK报文时表示客户端已经知道服务器没有数据要发送了随后正式断开整个TCP连接
客户端发送ACK报文后需要时间等待原因
若客户端发送ACK后马上释放了然后又因为网络原因server没有收到client的ACKserver就会重发FIN可能出现以下情况
client没有任何响应服务器那边会干等甚至多次重发FIN浪费资源client刚好有个新应用程序分配了同一个端口号新应用程序收到FIN后马上开始执行断开连接操作但是本来他想和服务器建立连接的
时间等待的确认
一般是2倍的MSLMAXimum Segment Lifetime最大分段生存周期MSL是TCP报文在internet上的最大生存时间每个具体的TCP实现都必须选择一个确定的MSL值RFC 1122建议是2分钟这样可以防止本次链接中产生的数据包误传到下一次连接中因为本次连接中的数据包都会在2MSL时间内消失
