昆明市城市建设档案馆网站,广州海珠建网站的公司,做的好的排版网站,四川网站建设广元分公司#xff08;八#xff09;客户端软件设计的细节
A、解析协议号
客户端可能会需要通过协议名指定协议#xff0c;但是Socket接口是用协议号指定的#xff0c;这时候我们就需要使用getprotobyname()函数实现协议名到协议号的转换#xff0c;该函数会返回一个指向protoent的…八客户端软件设计的细节
A、解析协议号
客户端可能会需要通过协议名指定协议但是Socket接口是用协议号指定的这时候我们就需要使用getprotobyname()函数实现协议名到协议号的转换该函数会返回一个指向protoent的指针。protoent的结构如下 B、解析服务器熟知端口
客户端还有可能通过服务名如HTTP标识服务器端口需要将服务名转换为熟知的端口号。
这时候我们就需要使用getserbyname()函数来将服务名转换为我们熟知的端口号该函数会返回一个指向结构servent的指针。servent的结构如下 C、解析服务器IP地址
客户端可能使用域名如baidu.com)或者IP地址如187.33.53)标识服务器。
IP协议需要使用32位二进制IP地址所以我们需要将域名或IP地址转化为32位IP地址。
调用Inet_addr()实现点分十进制IP地址到32位IP地址转换。
函数gethostbyname()实现域名到32位IP地址转换返回一个指向结构hostent的指针。 D、TCP客户端软件设计流程
确定服务器IP地址和端口号创建套接字分配本地端点地址IP地址端口号该步骤由操作系统隐式执行连接服务器套接字遵循应用层协议进行通信关闭/释放连接
E、UDP客户端软件设计流程
确定服务器的IP地址和端口号创建套接字分配本地端点地址指定服务器端点地址构造UDP数据报遵循应用层协议进行通信关闭/释放套接字
九服务器软件设计
A、四种类型的服务器
循环无连接Iterative connectionless、循环面向连接Iterative connection-oriented、并发无连接Concurrent connectionless、并发面向连接Concurrent connection-oriented
B、四种类型的服务器的基本实现思路
循环无连接服务器
创建套接字绑定端点地址INADDR_ANY 端口号这里的绑定是动态的绑定要根据客户端使用send or send to发送到服务端的IP和端口信息来确定绑定客户端地址。反复接收来自客户端的请求接收到一个客户端请求后即遵循应用层协议构建响应报文发送给客户端。这种方式每次只能服务一个人排队服务。
循环面向连接服务器
创建主套接字并绑定bind熟知端口号设置主套接字为被动监听模式listen准备用于服务。调用accept()函数接收下一个连接请求通过主套接字接收到新的连接请求后会创建新的套接字用于与客户建立连接和提供服务。注当没有请求的时候accept()函数是阻塞式的会一直占用线程等待。遵循应用层协议反复接收客户端请求构造并发送响应。当用户与服务器断开连接之后服务器关闭新套接字停止连接。
并发面向无连接
主线程创建套接字并绑定熟知端口号主线程反复调用recvfrom()函数该函数会获取客户端的IP和端口接收下一个客户请求并为接收的上一个请求创建并分配一个新的子线程。子线程接收一个特定请求根据应用层协议规定构建响应报文并调用sendto发送。子线程退出该线程一个子线程处理完毕一个客户端请求后就结束使命。
并发面向有连接
主线程创建套接字并绑定bind熟知端口号。设置套接字为监听模式准备等待客户端请求开始准备服务。反复调用accept()函数接收下一个连接请求通过主套接字同时创建一个子线程处理上一个接收到的请求创建新套接字的任务也交给该子线程。子线程接收一个客户端请求遵循应用层协议与客户端进行交互。当客户端发出指定中断指令断开连接后线程释放连接并退出。
五、传输层
一传输层传输层协议的作用
A、传输层协议
传输层为运行在不同主机上的进程提供了一种逻辑通信机制传输层主要负责将自己从Socket中收到的数据分成一个UDP或多个TCPSegment报文段或报文向下传递到网络层。或者负责将自己从传输层获得的Segment组合成数据向上传递给Socket继而到达应用层进行处理。
传输层为用户提供的协议主要有两种TCP可靠、面向连接、有序、数据流传输安全、UDP无连接仅实现传输基本功能像多路分用。
TCP为了做到有序、可靠就必须有相应技术例如拥塞控制、流量控制、连接建立。
以上两种协议都不保证带宽和延迟。
B、传输层和网络层的对比
传输层提供应用程序进程之间的逻辑通信机制仅用于网络层之上依赖于网络层服务增强网络层提供的服务。
网络层提供主机之间的逻辑通信机制。
二多路分用和多路复用
A、地位
多路分用和多路复用是传输层实现基本功能必须实现的。
B、原理流程理解 如上图host2上面有进程P1和进程P2host3、host4上分别有进程P4、P3。P3和P4都给主机host2发送消息分别对应host2上面的P1和P2。
多路分用就接收端而言当P4和P3的数据报Segment从网络层传到传输层时传输层通过每个Segment的“消息头”来确定Segment归属于哪个进程而后将信息交给对应Socket。
多路复用就发送端而言host2上两个进程P1、P2收到消息后返回响应信息通过传输层时传输层将信息分成一个或多个数据包并加上头信息注明要发送到的进程然后交给网络层。
C、UDP协议的多路分复用过程
先看UDP/TCP报文结构 每个从网络层到传输层的IP数据报会携带一个报文段Segment源端口地址、目的端口地址。
多路分用传输层协议在收到IP数据报后会根据报文“头信息”提取出目的IP和目的端口然后整理发送到对应Socket如此多种来源的数据报可以被导入同一个Socket。
多路复用应用层调用指令创建Socket不同Socket用二元组标识目的IP目的端口号传输层协议在发送应用层不同进程数据报时会分成多个报文段并加上源主机IP地址端口号目的主机IP地址端口号以及其他必要信息最后将传输层数据报发往网络层。
传输层还做了其他事情这里重点关注复用和分用故搁置不讲
下面是大概流程图 D、TCP的多路复用过程
TCP的分用和复用跟UDP很像就是多了一个源IP地址、和目的IP地址使用的是四元组标识。
服务器有可能支持多个Socket每个Socket都有自己的Socket标识Web服务为每个CLient开启不同的Socket每个Socket对应一个进程中的多个线程。大致过程如下图 E、UDP的细节再述说
UDP实现了传输层最基本的功能复用/分用简单的错误校验之所以要错误校验就是因为网络数据的传输会经过很多层再数据传输的过程中会发生数据乱码和错误的情况增加错误校验机制可以减少发送数据的错误如果接收方发现有错误就可以要求发送方从新发送。
因为UDP功能简单故其传输层报文的位数简单需要8位而TCP的报文头需要32位故实现简单。同时因为其发送的数据不是按序发送没有拥塞控制所以应用端可以更好控制数据发送的速率不像TCP协议会在传输层为了拥塞控制来不断变换数据的发送速率所以TCP的发送速率无法控制。
UDP无需建立连接无前置rrl时间所以比TCP发送数据更高效。
那么传输层是如何进行数据校验机制呢
发送方把数据内容看做是16bit的整数校验和计算计算所有整数的和然后将和的结果取反得到校验和放到校验和字段。发送方在发送数据的过程中连同校验和一起发送给接收方。
接收方收到数据后再次计算数据的校验和跟校验和字段中的位数进行对比如果不一致就表示发生错误一致就检测不出错误。
为什么说检测不出错误因为检测不出错误不代表没有错误可能会存在数据位两位正好都在传输过程中取反 结果也不会发生改变但是数据也发生了错误。
下面展示的是UDP的数据报结构一共32位bit 在数据校验的过程中如果数据位的最高位产生了进位那么最高位的进位要加到最低位上再取反。 这种数据传输不可靠的协议可以通过在应用层使用可靠的协议来保证数据传输的准确性和可靠性。
三UDP实现可靠传输
A、为什么要实现可靠传输
虽然传输层在截断分发传输数据报的时候会发送验证信息如果发现接收端发现错误可以及时返回发送方重传或接收到的消息从而保证信息传递的可靠性。
为什么会产生数据的错误从应用层看应用层只是简单的IP协议当网络拥塞时存在丢包的可能性数据链路层可能受外界影响部分数据发生变化导致数据错误因此就应用层而言其如果在传输层不经过任何处理那么面对的就是一个不可靠的数据通路。
我们在发送方和接收方通过传输层的协议保证数据对于两端的应用层是可靠的即应用层面对的是一个可靠的通路这样就减小了应用层软件设计者的设计压力。如上传输层面对的就是一个不可靠的通路channel传输层通过第一段中提到的应答机制实现数据发送端和接收端的一致。
结合下图可以更好理解这种思想 B、可靠传输协议的实现
现在们假设应用层已经面对的是一个可靠的协议传输层需要将实际不可靠的信道变得可靠主要依靠有限状态机和ARQ协议Automatic Repeat reQuest来实现。
有限状态机
可以理解为一台机器会对应不同的状态当状态发生改变之后这台机器会进行不同的操作这里的机器就是传输层不同状态就是接收到ACK信息和重传请求两种状态有限是指一个状态向另一个状态的转换是固定的不会同时转向多个状态。
下面是状态机的示意图 ARQ协议
该协议是基于拥有重传机制的rdt2.0协议。
该协议有ACK确认机制当接收方返回确认收到无误信息后发送方才会进入下一个数据发送流程。
下面模拟数据收发过程分析该协议如何利用有限状态转换机和消息接收确认机制实现变不可靠信道为可靠信道的过程。 发送方分析如上图左边是消息发送方rdt_send(data)应用层将数据发送到传输层传输层将数据分段snkpktmake_pkt(data,checksum)同时添加验证码用于检查错误然后不可靠发送数据udt_send(sndpkt),发送完毕状态机发生状态迁移由等待请求变为等待ACK 或者 NAK响应。
下面有两种情况情况一接收方接收到数据并且数据无误则发送方状态机通过rdt_rcv(rcvpkt)isNAK(rcvpkt)来接收到ACK反馈后跳转状态到等待接收下一条指令Wait for call from above。
情况二接收方接收到数据数据发生错误返回NAK信号则发送方状态机还是通过rdt_rcv(rcvpkt)isNAK(rcvpkt)来接收到NAK反馈之后跳转到本状态Wait forACK or NAK),并且重新发udt_send(sndpkt)。
接收方分析如上图右边是消息接收方。两种情况。
情况一在接收到错误数据时rdt_rcv(rcvpkt)corrupt(rcvpkt)为true则执行udt_send(NAK)命令发送错误接收到发送端同时状态机跳转为本状态因为仅有一个状态。
情况二再接收到无误数据时rdt_rcv(rcvpkt)notcorrupt(rcvpkt)为true则udt_send(ACK)发送确认信息到发送端send。
C、Rdt2.1
Rdt2.0存在的问题
Rdt2.0中使用ACK和NAK发送到发送方来确认接收端收到数据的情况但是没有考虑发送的ACK/NAK消息错误问题Rdt2.1就是解决这个问题的。
所以我们需要在发送方传输层的状态机中增加状态用来处理当返回ACK/NAK消息错误情况的。
这里先假设我们发送方收到了错误的确认消息然后重发接收方就接收到了两次一样的数据故需要在数据上增加序列号来区分两次一样的数据从而让接收方可以判断重复数据而将重复数据丢弃。
序列号只需要0和1两个即可因为这里Rdt还是停等协议收不到确认消息不会发送下一条。
下面根据一张状态图来分析当ACK/NAK发生错误时发送方状态机的步骤流程 从上面开始看起应用层发送数据到传输层rdt_send(data)传输层收到后分组并添加验证码和组包号然后发送到接收端udt_send(sndpkt),同时进入等待状态Wait for ACK or NAK 0)。
这时候如果接收方返回数据错误或返回确认信息有误都会使corrupt(rcvpkt)||isNAK(rcvpkt)的值为false从而触发重发机制重发组号为0的组。然后继续进入原状态。
这里有个注意点重发后接收方接收到了两个序号序列号为0的数据包就会判断重复所以会保留一个丢掉一个这也是我们加序号的原因
如果重发后接收端返回的是正确的信息同时为ACK则状态机跳转到下一状态等待组号1的包从上层发送Wait for call 1 from above然后发送下一个数据包到接收端。
然后接受端还是有两种情况跟数据包0情况分析一致就不再分析。
下面是接收方流程图 D、Rdt2.2
Ret2.2还存在什么不足
我们看到Ret2.2返回消息还是两种ACK信息正确接收/NAK消息存在错误这样两个消息可以合并为一个消息ACK 序号即可从而减小接收方存储容量提高效率。
那如何判断接收方返回的接收错误消息接收方只会返回已经接收成功的包例如ACK 0如果下一个接收到的1发生错误还会返回ACK 0则发送方就明白包1发生错误回到原状态重新发送。
整个过程如下图 如上图在0号消息通过udt_send(sndpkt)发送出去之后状态机来到状态Wait for ACK 0如果返回消息为1号接收成功证明0号发送失败。isACKrcvpkt1|| corruptrcvpkt会因为返回ACK错误、序号为1、消息存在错误而为false从而触发重发机制重新发送0号序号数据包。
左下是接收方的流程逻辑。
E、Rdt3.0
Rdt2.2中存在的问题
Ret2.2中减小了发送方的信号类型只使用ACK即可但是前面所有假设都没考虑到丢包的情况Rdt3.0重点解决了发送包丢包的问题。
如果我们发送的数据包在传输过程中因为网络拥塞路由储存不够丢包等等情况丢失那么我们一定收不到接收方返回的任何信息。
所以我们需要给发送方设定一个超时时间timeout一旦发送数据包后超时时间到就重新发送数据。如果在超时时间内收到确认消息就“无事发生”。
我们需要给接收方增加计时器来记录超时时间。
下面给出修改后发送方的状态机图 触发超时的各种情况分析
上面提到的数据包丢失超时后触发重传。接收方收到数据但是ACK消息返回过程中丢失那么也依然会触发发送方重发机制同时接收方收到重复包后丢弃重复包。如果数据包接收方确实收到了接收方也发送了确认消息ACK 0但是因为网络延迟原因ACK还在传输的过程中接收方等待超时触发重传。那么就接收方而言会判断重复丢弃重复包。该种情况具体流程如下图 这种情况值的分析上图我们可以看到接收方因为网络延迟原因ACK1到达发送方前发送方就重发了包1而后收到了接收方对上一条包1的迟到回复然后发送包0。
但这就产生了问题第二个包1的回复会怎样被发送方处理呢很明显因为接收到第二个ACK1时发送方处在等待ACK 0的状态中所以会触发发送方重发机制重发包0接下来只要一切正常网络无延迟接收方会发送两次ACK0两次ACK0都会在发送方接收到第一次ACK0时准备发送包1时到达从而一切回到正轨后面是个人猜测有不对还请斧正
F、流水线机制
为什么要引入流水线机制
要研究这个问题我们要先知道原来的Rdt3.0协议的停等模式所带来的带宽的严重浪费问题。
假设我们现在的链路是1Gbps15ms端到端传播延迟1KB分组我们先计算1Gbps链路传送1kb需要的时间链路是以bit为单位传输的所以计算过程如下 可见我们需要8ms。
那么我们发送方的利用率发送方发送时间百分比 RTT是数据往返时间两次数据发送需要等待一个数据往返时间。所以计算出来的发送方对带宽的利用率是0.00027并且在1Gbps的链路上每30毫秒才发送一个分组1秒才发送33KB。
所以可以看出Rdt3.0协议限制了物理资源的利用所以我们就需要引入流水线机制。
引入流水线机制前我们的发送过程如下 引入流水线之后我们的发送过程如下 我们像流水线一样一个发送完毕在等待的过程中继续下一个消息发送,这样就相对压缩了RTT时间。这样我们的利用率就提高为0.0008提高了3倍。
G、滑动窗口协议Sliding-window protocolGBN、SR等
要想实现流水线就需要用到滑动窗口协议当滑动窗口协议。
滑动窗口协议有哪些特征呢首先它规定的窗口概念允许使用很多序列号原来的0和1已经不够用了窗口尺寸N代表最多有N个等待确认的消息。
为何为滑动因为随着协议的运行窗口序列号空间会向右前滑动发出的已经接收到的消息会被移出窗口从而扩展窗口的有效容量。下面是示意图 send_base是窗口起始位置。nextseqnum指向窗口中下一条要发送的消息。window size指窗口总共能够支持多少消息等待ACK返回。窗口内的黄色部分没有一条收到ACK后窗口就会向右滑动。绿色代表已经发送并接收到返回信息的消息已经被划到了窗口以外。黄色代表已经发送出去消息但是还没有收到ACK的消息蓝色代表窗口内剩余的可用序号。最右侧是还没有移到窗口内的部分。
GBNGo-Back-N)
其是滑动窗口协议的一种具体实现将k-bit序列号包含在分组的头部窗口尺寸为N因为支持多个发送方流水线发送请求所以接收方接收数据后的确认消息为累加确认如接收方接收到5个数据返回确认信息ACK 5 即代表序号5以前的数据都被我收到了
那么GBN协议的接收方如果碰到数据乱序发送该如何处理比如本来3接收完毕应该该4了但是却收到了5这时接收方就会直接丢掉5返回ACK 3表示接收到3号。
GBN发送方的重传机制通过计时器timer控制一旦到规定时间已经发送的数据没有得到回应的序号就会被依次重新发送下面分析具体细节
数据发送方的有限状态机 从图中最上方看起先发送数据rdt_send(data)然后三个条件判断
如果窗口中下一条发送数据的序号nextseqnum) 窗口最左端序号base 窗口总序号数N则将数据打包加入序号和验证位发送。如果窗口最左端序号base和下一条要发送的序号nextseqnum相等代表窗口中还没有一条数据发出则开启计时器start_timer,然后开始流水线发送数据将要发送的数据序号向右移动一位等待数据发送。其他情况就是窗口移到尽头只能等待拒绝发送请求。
右方就是计时器timer时间到后重启计时器start_timer并且重新发送已经发送但未收到回复的消息的过程udt_send(sndpkt[base])...
下方过程是发送方接收到接收方确认消息ACK后的操作。先判断接收到的消息是否为ACK正确接收rdt_rcv(rcvpkt)notcorrupt(rcvpkt))然后根据累计确认消息序号再加上1得到新的窗口左端也意味着已经收到ACK的部分被移出窗口然后判断是否窗口中所有已经发送的消息都被确认basenextseqnum)如果为true则停掉计时器如果为false保持计时器开启。
数据接收方的有线状态机 在开始等待之前有一个期待序号expectedseqnum11是下一个要取入的序号如果不是期待的序号则会被直接丢弃如期待的是1但是因为链路原因2先到达直接无脑丢弃我只需要序号1的数据。
默认default如果接收序号正确则会执行udt_send(sndpkt)发送逻辑上层收到rdt_rcv(rcvpkt))后判断是否无误、是否是期待的序列号数据hasseqnum(rcvpkt,expectedseqnum)notcurrupt(rcvpkt))如果都为true则正常向上层发送数据。deliver_data(data),然后打包确认信息sndpkt make pkt(expectedseqnum,ACK,chksum)最后发送确认信息udt_send(sndpkt))并将期待序号加1expectedsqnum。
SRSelective Repeat协议
上面的协议导致严重的资源重传从而产生了大量的资源浪费。因为每次重传都是将其序号及以下序号全部重新发送。
该协议接收方接收一个消息就确认一个消息不同于GBN协议累计确认接收方也有一个滑动窗口。
该协议接收放增加了缓存区当接收到没有按序提前到达的数据就将数据放到缓存区中然后发送确认接收。
发送方每个数据项都对应一个计时器timer当计时器时间耗尽时仅会重发对应的一条数据。
协议具体图示如下 发送方黄色部分是已经发送但还未收到接收方ACK的数据青色是已经收到接收方ACK的数据蓝色是在窗口内还没有相关序号数据发出的空余的序号。当最左端收到ACK则窗口则会向右滑动至第一个已发出但没有回复的数据黄色。
接收方接收方窗口中的数据是等待接收的数据灰色是还没有收到的数据序号红色是乱序收到已经放在缓存区中并返回ACK信息的数据。蓝色是空闲的还没有用的序号。最左端每确定收到一个数据后窗口就会向右滑动。
下面模拟一次数据的发送 发送方依次发送四个序列数据0、1、2、3。2组数据在传输过程中丢失接收方先收到0组数据窗口向右滑动1位然后又收到1组数据窗口继续向右移动1位此时接收方最左边是期待的第2组数据但是2组数据已经丢失。第三组数据到达后因为2组数据还没收到3组数据就被放到数据缓存区中并返回ACK信息给发送方。此时2组数据的timer时间还没有耗尽发送方继续发送4、5组数据4、5组数据都顺利到达被接收方放到了数据缓存区中。此时发送方中的所有序号都已经用光因为2组数据还在等待故窗口无法右移。接收方同样期待的数据窗口中的数据除了2组数据都已经接收到了窗口因为2组数据也无法右移。同样窗口停止等待2组数据。接收方2组数据的timer时间耗尽重发2组数据接收方接收到2组数据后连同之前放在数据缓冲区中的3、4、5组数据一块发送给上层应用同样窗口一下子直接向右移动4位最左端send_base指向6组数据。发送方同样在收到接收方的ACK后直接向右移动4位开启新的数据发送。
SR的困境注意点 像上图两种发送与接收的情况最后两个接收方虽然都是接收到了0号数据但是却不是同意个数据。
上面的接收方因为返回的三个ACK消息都丢失了所以当0组数据timer时间到后重新发送的还是原来的0组数据。
下面的接收方收到了发送方的0、1、2号消息跟上面一样窗口都移动为3、0、1。当接收方返回0组消息ACK时发送方同时发送3组数据但是3组数据丢失了这样接收方最左端在3组数据重发之前窗口就无法向右移动这时发送方已经接到了1组数据的ACK窗口移动到了2、3、0的位置第二个0组数据发送但是接受方因为窗口一直无法右移一直在等待第一个0组数据因为接收方仅识别序号故把发送方第二个0号数据当作第一个0组数据进行接收从而导致数据错乱。
解决这个问题就是增加序号总量这里我们必须满足发送方窗口序号容量 接收方数据容量 要发送的数据组数量。
四UDP实现可靠数据传输
A、TCP协议特征回顾
点对点一个接收方对应一个发送方是可靠的、按序的字节流传输采用流水线机制拥有流量控制和拥塞控制机制能够设置窗口尺寸。接收方/发送方都设有数据缓存。全双工同一连接中能够传输双向数据流。面向连接只有当连接建立时才能够相互发送数据。这种连接状态是在两端维护沿途节点不协助维护连接。TCP规范中没有规定对乱序到达的数据的处理方式由TCP协议实现者决定。
B、TCP报文段segment解释 source port\dest port 源端端口号/目的端端口号、
sequence number 序列号这里序列号是根据已经发送的字节数来分配的比如上一条segment是8字节则该条报文段segment的序号就是9。
acknowledgement number 对某一报文段的收到ACK回复。
URG 紧急的数据用序列号标识通常不用、ACK 有效ACK标识、PSH 立即向上层发送数据通常很少用、RSTSYNFIN 开始建立连接维持连接终端连接、Internet checksum 互联网验证位码。
application data 数据发送位。
C、TCP协议的细节跟UDP安全传输不同之处
累计确认消息接收方接收到消息后发送ACK 序号 代表序号之前的数据都已经被接收到了。TCP使用统一的计时器timer但是当计时器时间到时仅重新发送引起计时器时间耗尽的数据组。触发重传机制有两种途径timer耗尽等待超时、收到3次重复ACK因为接收方采用的是累积确认机制当收到乱序到达的数据会不断发送期待接收的数据序号直到发送方重新发送同样如果从接收方收到ACK 确认消息则发送端窗口可以向右移动因为累积确认会发生100200组都在等待但是收到ACK 200则窗口直接右移100个序号。当然这时如果窗口中还存在201组数据发送而未确认则开启timer。
D、三个例子演示 这里省略了Host A 和 Host B建立TCP连接的过程
左边例子HostA 发送第一个报文段segment序号为92大小是8字节。Host 收到消息之后回复收到ACK 100TCP采用累计确认机制因为92字节加上8字节为100字节表示收到100字节数据下一个发送方应该从101序号发送。但是不幸接收方的ACK 100丢失了。发送方等待时间耗尽则重新发送92号数据然后接收方再次发回确认信息。
右边例子在流水线窗口协议的控制下发送方依次发送两组数据92、100,并且收到ACK 100 ACK 120但是接受方timer设置太短在收到ACK前已经重发了92号数据接收方收到数据后发现不是自己期待的121号数据故返回上次收到的序号确认 ACK 120。
再看下面例子 因为是累计确认所以即使接收方Host B接收返回ACK 100丢失了但是ACK 120相当于累计确认了100号数据故发送端100号数据不需要重发。
E、不同情况下接收方的策略 情况一、当接收方按收到了发送方传来的数据时并不会立即返回ACK消息会等待50ms看看是否能够收到下一条数据。
情况二、当接收方收到发送方传来的数据的时候并且发送方还存在之前发送过但并未收到ACK时接收方会在收到数据后立即返回ACK信息。
情况三、当接收方收到不是自己期待的数据时会返回前一个成功收到的数据序号。
情况四、当发送的数据报文有缺口时会发送报文缺口处的序号给数据发送方。
F、流量控制
当TCP协议建立连接的过程中接收方会分配缓冲区buffer缓冲区中专门用来存放接收到的数据包括乱序到达的数据因为buffer有大小如果发送方发送数据报文segment速度太快那么接收方的buffer就会被占满从而导致数据丢失。并且上层应用读区速度要慢于接收速度故很需要流量控制。
如下图 如上图最右边箭头是应用进程它会读区缓存区中的数据绿色条纹部分是已经占用的buffer部分蓝色是空域部分。
spare room 可以如下计算LastByte指buffer中已经有的字节LastByteRead指应用进程已经读区的数据字节数 RcvWindow RcvBuffer -(LastByteRcvd -LastByteRead)。 每次接收方接收到Segment时都会在返回ACK报文中的Revwindow项中标注buffer剩余的空间大小发送方收到之后就会做出相应的合理的流量发送调整发送速度。
当接收方接收数据后buffer被占满后返回ACK信息含有Revwindow满的信息接收方收到后并不是不会再向接收方发送消息因为如果没有发送方给接收方发送消息接收方就无法通过ACK把最新的buffer容量回馈给发送端而是为了避免死锁还是会不断向接收端发送小数据端以期获得最新buffer情况。
TCP三次握手建立连接过程
都由client端发起连接请求第一次Client初始化自身缓存区和序列号然后向服务端发送SYN标识为1的请求第二次接收方再收到之后分配自己的buffer和Seq序列号等信息然后发送ACK确认消息。第三次Client在收到ACK消息后再发送SYN0的消息表示自己收到了服务端确认收到的信息。连接建立。如下图 TCP四次握手连接的断开 之所以Client等待第四步原因是自己的ACK信息存在丢失可能等待一会是server端一段时间收不到ACK重新发送FIN确保两端都断开链接。
下面是发送方和接收方的状态变化图 五TCP的拥塞控制
A、拥塞控制是什么
在网络中太多主机同时发送了太多数据而导致网络处理不过来路由缓存被占满网络不通畅。跟流量控制不同的是拥塞控制关注的是共同的网络流量控制关注的是发送方和接收方。
网络拥塞多表现为路由器缓存被占满数据包丢失数据在路由器的缓存中排队导致延迟时间过长。
B、网络拥塞后果发送速度过快数据在路由器中排队延迟过大 假设路由器有无限缓存同时因为有无限缓存数据不会丢失所以发送方不需要重发。
original data就只有要发送的数据包接收端也仅需要接收新的数据包即可。
当Host A、Host B向网络中同时快速发送大量数据包时路由器处理不过来就将数据包放到缓存中排队发送。这时我们可以根据下面图分析发送速率in 和 输出速率out的关系 当发送速率超过C/2带宽的一半时数据就会开始排队所以一直会有输入排的队伍越来越长而out数据远慢于in数据的速度故可以从右图中看出当发送速率in无限接近C/2时延迟时间delay也就无限长了。
为什么时一半带宽我的考虑是网络的分层结构需要预留空间给其他层增加消息头同时因为双工通信原因所以需要预留一半空间个人理解。
C、网络拥塞后果路由器缓存太小导致数据丢失 因为这里路由器的缓存是有限的所以会存在数据丢失可能性TCP协议会重新发送数据重新发送的数据会占用流水发送增大in的大小图上表示为‘in我们要明确重新发送的数据因为之前发送过所以重发时不算在有效数据中它只是在弥补之前的数据丢失。
由上可知因为路由缓存有限存在数据重新发送导致有效数据占比变低所以当发送方速率和数据量增加时out会在顶峰后无限接近0因为你速度越快丢失的数据包越来越多触发发送方重发重发数据越来越大故有效输出变得极低无限接近于0。 D、网络拥塞后果上游网络层节点路由器传输能力浪费。 上图中每个颜色都是一条数据流我们观察红线从Host A发送到 Host C它发送数据包经过了两个路由器上、右再观察绿线Hsot D 到 Host B绿线发送经过两个路由器右下这两条线路共同通过右路由器当Host D、 Host A发送的数据过大过快时右路由器产生拥塞A、D两个主机的数据都有可能丢失这样A的数据经过上路由器时的处理被浪费上游处理能力全部被浪费掉。
E、拥塞控制的两种类型
类型一端到端拥塞控制Internet网络采用
不需要网络层配合端系统通过丢包loss率、和延时delay情况等做出网络是否发生拥塞的判断。TCP即采用该种方法。
类型二网络辅助拥塞控制
路由器会向发送方显示地反馈网络拥塞信息。简单的拥塞指示改变数据中某一位代表拥塞同时这种拥塞控制可以指示允许的最大速率。ATM网络等就采用该方式。
简单介绍ATM的网络辅助拥塞控制 如上图RM cells 是发送方在发送数据过程中夹杂的RM控制 cell每经过交换机ATM中的数据包交换机都可以指示NI bit位 不允许速率增长 、CI bit位拥塞指示、ER 能够支持的最小速率。这些RM到达接收方后接收方会发回发送方发送方可以根据这些RM cells中记录的信息获得拥塞情况并作出相应调整。
当然data cells中也可以包含EFCI位发生拥塞的交换机可以将EFCI位置1当接收方发现EFCI为1则会在接下来的RM cells中置 CI拥塞位发送到接收端。
F、Internet采用的拥塞控制原理详解 采用端到端拥塞控制根据发送端发出的数据被接收到的数量确定自己是否产生拥塞有两种情况
发送端收到接收端三次重复的ACK请求。发送的数据包超时事件发生。
拥塞控制下发送速率不是直接开到最大开始时是指数增长当到达Threshold时就变为线性递增当达到拥塞点时就更新ThresholdThreshold 1/2 * 拥塞点速率然后根据引起拥塞类型判断拥塞控制的速率应该降到何种程度如果是timeout事件引起则速率直接降到0如果是3次重复的ACK则降到拥塞点的一半继续线性增长线性增长每次的值为MSS。
上面的过程就像下图所示所谓加性增-乘性减。 六、网络层
一网络层和传输层的区别、网络层的主要功能、几种网络层服务模型的对比
传输层针对的是端到端层面的连接UDP和TCP协议看到的网络层是透明的网络层需要两端的路径中所有网络设备参与其中比如路由器网络层协议
主要功能转发将从传输层来的数据报从输入端口导向合适的输出端口。路由根据自身的路由表和路由算法得出要将数据输入到哪一路径上这就叫做路由。
不同网络层协议如下 二两种服务类型
A、无连接服务connection-less service)
不会事先为传输确定固定的传输路径每个数据报传输的路径可能不同可能会产生数据报乱序到达的问题。
代表网络数据报网络datagram network
B、有连接服务connection service
首先为系列分组确定从源到端的传输路径确定之后每个数据报都会携带一个VCID虚电路号路径上的所有网络设备路由都要参与维护虚电路的连接状态每个数据报传输的路径相同传输结束后拆除连接。
代表网络虚电路网络virtual - circuit network
C、为什么叫虚电路网络
可以通过预存技术实现电路网络的通信保障同时源主机和目的主机维持逻辑连接。
虚不像电路网络靠分频来分配用户虚电路网络依然是分组交换网络所以没个数据报发送过程中都是占用完整带宽。
三虚电路网络介绍
A、虚电路网络的组成
是从源主机到目的主机的一条路径。每段路径都有一个独特的VCID虚电路号发送的数据包通过VCID确定发送路径。沿途的网络设备记录数据报经过的每段虚拟电路负责维护路径转发路由。
同一条路径在每段上的VCID不同因为在不同的链路其最大带宽有区别所以支持的链路有不同虚电路号范围自然不同。
网络设备路由器在收到数据报后根据转发表改写到来的数据报将VCID改写为下一个需要的VCID。转发表大致格式如下 B、虚电路信令协议signaling protocol
它是实现虚电路路径中生成转发表建立连接路由时的规范是实现虚电路的协议。
下面是建立连接拆除连接的过程 VCID在初始呼叫和接受呼叫过程中就被确定路径选择过程数据流流动完毕后连接就可以被断开。
该协议目前被ATM、帧中继网络广泛采用Internet是数据报网络没有采用信令协议。
四数据报网络介绍
A、网络层无连接internet采用的是数据报网络每个数据报携带要到达的分组到达目的主机的分组可能是路径不同的。 B、数据报网络和虚拟电路网络的对比
internet网络的网络沿是计算机使用的是数据报网络因为计算机是复杂结构所以可以进行纠错等复杂机制这就要追求网络层的简单可用。即所谓的简化网络复杂“边缘”。ATM网络使用的是虚拟电路网络该网络是由电话网络演化过来的改网络要求具有严格的可靠性和时间性所以网络层是复杂的和可靠的简化网络边缘复杂网络。
C、如何寻址internet网络层
因为没有固定线路所以每个路由器都要根据数据报中的目标地址IP做出判断指出其下一个路由器地址但是全球有40亿IP地址如果每一个地址都分别在路由器中有对应那么对于路由器来讲是不可实现的故我们用地址范围取代具体的地址值这样就大大减少了路由器处理的容量路由器对应的IP范围如下 当数据报的地址对应两个范围两个范围对应不同的输出端口这时我们应该以范围最精确的对应输出端口为主。如下图所示例子 对应匹配的有两个接口1、2因为1接口的范围更小更精确最终会从链路接口1中输出信息。
C、路由协议、IP协议、ICMP协议的关系
路由器根据路由协议计算出路径对应信息储存在转发表中IP协议负责规定寻址规范规定数据报格式ICMP协议和IP协议相伴而生负责规定数据报差错控制规范路由器发送信令信息规范。
D、数据报结构分析 版本号4个bit0100是IPv4协议0110是IPv6协议首部长度4个bit以4个字节为单位,例如0001表示该数据报首部长度为4字节。服务类型区分服务8个bit指示期望使用路由器的哪种类型的服务。只用当网络提供不同区分服务时才有效一般情况下不使用通常IP分组的该字段的值为00H。总长度16个bit位表示整个数据报首部数据的总长度。以1字节为单位所以计算可得数据报分组最大长度为65535字节最小的分组首部20字节所以能够封装的最大数据大小是65535-2065515字节。标识、标志位、片偏移后面会提到先搁置不提。生存时间TTL8bit一个字节。记录允许数据报经过的路由器个数每经过一个路由器该数据减1当TTL为0时会被接收到的路由器丢弃路由器在丢弃后会根据ICMP协议向发送方发送消息告知数据包过期。协议8bit。指定该数据报是对传输层什么协议数据的封装例如是封装的UDP数据则为17代表封装的是TCP则为6。首部检验和16bit跟传输层UDP协议的数据检验规则原理一样对所有数据作相加操作如果超模则循环累加在末位加1最后取反。该字段作为校验字段用来校验数据在传输过程中是否发生错误。每经过一个路由器校验和都会从新置零然后从新计算。源IP地址32bit用来指定来源主机或者路由器。目的IP地址32bit用来记录要到达的目的主机/网络设备的地址。
五IP数据报分片
A、为什么会有分片
在网络层的下一层数据链路层中因为不同的链路有不同的MTU最大传输单元所以当IP数据报大于链路层的MTU时就需要对IP数据报作分片操作就是将数据分多个部分传输这些小的部分就是片。
B、分片的一些细节
路由器在进行分片之前会按照IP数据报中的标志位中的DF位来确定是否进行分片如果IP不允许分片则会被丢弃。
因为internet网络的简单原则分片之后要到目的主机之后才能够从新组装。设想如果在网络层中某个主机组装那么势必还会遇到MTU更小的链路从而导致再次分片浪费资源拖慢效率。
分完的片首部信息中ID段的值还是相同的用来确定是同一个数据报的不同分片如果接收端主机在接到片后发现少片会等待一定时间一旦超时则会丢弃对应数据报的全部片信息。
C、IP数据报的细节再追述标识、标志位、片偏移
标识ID
路由器根据自己生成的报文数量赋予IP报文标识ID字段值没有什么参考意义因为不同路由器会都会发送第n条数据。
标志位
标志位3个bit分别是保留位、DFDon‘t Fragment、MFMore Fragment DF1禁止分片DF0允许分片MF1不是最后一片MF0是最后一片或者未分片
那么如何区别MF的0到底是分片的最后一片还是没有分片这需要我们根据片偏移来判断。
片偏移
片偏移量占用13位以8字节为单位即每增加1代表8字节。所以片偏移只能是8字节的倍数。
上面的问题很好回答如果片偏移为0且MF0肯定是没有分片如果MF0且片偏移为非零则肯定是分片的最后一片。
D、关于分片的一些公式 六IP地址、网络接口、子网
A、IP地址
IP地址32位bit编号标识主机、路由器的接口因为二进制的32位数不便于记忆所以一般人们都转化为每八位为一组的十进制表示如223.1.1.1
前面提到过全世界拥有的计算机数量超过40亿每一台都有一个唯一IP放在路由器的转发表中无疑是不现实的。
IP地址的组成网络子网号 主机号 B、子网
所以我们在分配地址时将同一地区互相通信不需要跨越路由器的多台主机标识为一个子网用IP地址的前一部分标识子网在同一个子网中的主机路由器在转发时看作一个整体。 C、网络接口
主机用来和链路通信的路由器用来和链路通信的部件叫做网络接口同一个主机/路由器可以有多个网络接口如笔记本电脑有无线网络接口和有线网络接口等。
七IP地址的分类、子网掩码
A、IP地址的分类 如上图根据网络ID占用位数和HostId占用位数的不同来将Ip地址分为不同类型A类地址占用8位。这样剩下24位就负责子网的定位这样就导致子网数量过少。B类地址占用两个8位作为网络地址。C类地址占用三个8位作为网络ID为了区别不同类别的IP地址用最前面的位数来识别比如第一位为0的就是A类地址。D类地址没有HostID一般用来作为广播之用。E类地址多用于研究。
一些特殊的IP地址也不能使用如下 B、IP地址的再细化
较之前的IP结构我们不同网络还需要划分不同子网故结构作如下变更 那么紧跟着另一个问题就又来了有了子网我们应该如何确定一个IP地址是否划分子网划分子网占用了HostID的多少位
所以我们就引入了子网掩码的概念。
C、子网掩码
子网掩码取值很简单就是将网络IDnetID和子网IDsubID对应为全部取1HostID位全部取0在这一规则下不同类型网络的点分十进制形式如下
A类255.0.0.0B类255.255.0.0C类255.255.255.0假设B类网借用Host3位作了子网IDSubID那么二进制下就有三位0位变为1则点分十进制形式下就为255.255.224.0。
如何根据子网掩码和IP地址结合起来知道子网的地址范围 只需要将IP地址和子网掩码地址按位进行与运算当二者相同为1否则为0最后就能得出子网地址范围172.32.0.0 172.32.1.255 因为HostID全0或全1有特殊含义所以真正范围为172.32.0.1 172.32.0.254.可见这里第三个8位七位都被作为subID且SubID中全为0SubID取值也会影响HostID的取值范围。下面是以C类IP为例不同SubID取值hostID可用范围的表。 略微解释因为SubID是HostID的一部分所以SubID的取值就决定了HostID的整体取值范围。
D、CIDRClassless InterDomain Routing无类域间路由
上面按类对IP地址进行划分存在IP地址浪费的情况比如当一个单位需要2000个IP地址分配给其一个A类地址太多一个B类地址太少无论怎么分必然会造成浪费。同时加上子网掩码也使IP变得更为复杂。
CIDR就解决了这个问题它将IP地址中NetID和SubID合为一个叫做前缀。在IP地址后加上一个信息来指定前缀长度这样就摆脱了IP类的束缚。下面展示使用前后对比 使用CIRD的优点如下
提高路由效率将多个子网构成一个更大的子网这样在主干网等上层网络的路由器中路由表就可以简化如下表
正常是三个子网三个项虽然都对应同一个输出端口2。 通过改变前缀我们就可以将表项简化为红色部分这样就提高了路由效率。
E、IP地址静态获取
在本地计算机中指定即可 F、IP地址动态获取DHCP Dynamic Host Configuration
通过网络中的DHCP服务器动态分配在动态分配IP地址同时也会动态分配子网掩码、默认网关地址、DNS服务器名称及IP地址。
优点随时可用允许地址重用、支持地址续租、支持移动用户加入网络。
流程要加入网络的主机先发布广播报文DHCP discover如果网络中有正在运行的DHCP 服务器的话就会发送DHCP offer进行响应收到响应后主机再次发送DHCP request请求报文收到后DHCP服务器分配IP地址 DHCP Ack确认报文。
八NATNetwork Address Translation网络地址转换
随着IPV4地址的分配殆尽NAT思想横空出世。它一般在路由器中实现通过一张地址转换表将只能在内部使用的IP地址转换成能够在公网使用的公网IP。
这样整有几大优势
当要变更ISP网络运营商时无需通告外界网络自己本地地址IP可以保持不变。本地内部网络是不暴露在公网上的具有极大安全性。
A、工作原理 当路由器接收到来自本地网络的IP地址和端口号后就会将信息中的IP地址修改为公网IP地址当有消息进来后再根据转换表中内容将公网地址转换为对应本地地址进行消息发送。
B、P2P应用如何破局
因为路由中有NAT机制所以P2P类应用如何绕过NAT直接实现两个端的通信
方案一静态配置NAT将路由器中NAT转换表中P2P应用对应的公网地址和端口固定下来这样就可以实现P2P通信。
方案二自动配置利用UPnP互联网网关设备协议让一端能够实时获取到NAT转换表中信息能够实时控制转换表中公网和本地IP地址的对应关系。
方案三中继如Skype通过互联网总一个服务器实现连接的保持这样也可以实现连接。如下图 C、NAT的争议
违背了层次性结构的原则因为路由器属于网络层网络层应该只负责第三层功能但是NAT却干涉传输层将传输层数据进行修改这就违背原则虽然解决了IP地址不足的问题但是很多人还是认为IPv6才是解决IP地址不足问题的最终归宿。
九ICMP协议
A、ICMP协议的运行
ICMP协议用来处理数据再发送过程中出错、线路探寻等情况。ICMP报文有两种类型
类型一差错报告报文以下五种情况会触发差错报告报文
目的不可到达源控制拥塞时通知源主机发送速度控制数据报超时或者超期数据参数出现问题重定向不该本路由器接收通知转发
类型二网络探寻报文
回声请求与应答报文像trace程序可以利用ttl控制数据经过的路由数统计出线路经过的路由器数时间戳请求与应答报文。
B、ICMP协议报文的结构 对应不同的类型和代码代表不同的情况具体情况明细如下 以差错报文举例见ICMP报文装入IP数据报文的结构 C、不发送ICMP报文的情况
对发生了差错的差错ICMP报文不发送ICMP报文。被路由器分片后的的数据片除第一个分片外后续分片出错不发送ICMP报文。所有多播IP数据报文均不发送ICMP报文。对具有特殊地址表示如127.0.0.0或0.0.0.0的数据报不发送ICMP报文。在实际应用中信息请求与应答报文、子网掩码请求与应答报文、路由器询问与通告报文都不再使用了。
十IPv6协议网络
A、IPv6数据报结构 IPv6取消了IPv4可变首部长度固定位40字节同时取消了可选项代之以扩展首部。
取消了校验和减少每跳处理时间同时衍生出ICMP6协议该协议支持多播组的管理功能。
优先级通过该字段指定数据的优先级供网络更合理分配资源。
流标签标识数据所用于的服务类型讨论中统一流中数据用于同一服务。
源地址/目的地址32位变为128位。
B、IPv6地址表示 压缩形式不允许同时使用多组双冒号代替0。
IPv4-嵌入形式将将一部分用0占位一部分用1占位留32位来集成IPv4的地址。
C、IPv6的地址类型 多播和任意播类型的地址只能做目的地址。
D、如何实现IPv4到IPv6的过渡 隧道技术 在遇到仅支持IPv4的路由器时上一个支持IPv4和IPv6的路由器就将IPv6的数据报文再封装一层变成IPv4数据报文直到遇到支持IPv6协议的路由器后再拆为IPv6数据报。
