计算机网络——运输层

来源:互联网 发布:excel 一列数据递增 编辑:程序博客网 时间:2024/05/21 17:45

1、概述:运输层提供端系统进程之间的逻辑通信;网络层提供端系统之间的逻辑通信。运输层将应用层报文分成报文段,封装上运输层首部报文段交给网络层,网络层将其封装上网络层首部字段成为数据报。

1.1套接字:进程与网络之间的门户。

1.11一个进程有一或多个套接字。高性能Web服务器通常只有一个进程,为每个客户机的连接创建一个线程,一个线程一个套接字。

1.12 UDP目的地是同一主机同一端口号的报文段交给同一套接字;TCP这种情况交给不同套接字,除非TCP携带初始创建连接的请求。

1.13如果客户机与服务器用持久HTTP,客户机与服务器之间经由同一服务器套接字交换HTTP报文;非持久的HTTP则对每次请求/相应都建立一个TCP连接。

2、多路分解与多路复用

2.1多路分解:接收端:运输层接收报文段检查端口号(套接字唯一标识符)将其交给正确的套接字。

2.2多路复用:发送端:从源主机不同套接字收集数据块,为数据块封装上信息生成报文段,将报文段传递到网络层。

3、可靠传输原理:

3.1接收方进行差错检验,回复接收方 所收到的报文段是否正常(正常:ACK,不正常:NAK)。也可以对上次收到的正确报文段进行冗余确认代替NAK

3.2停等协议(发送方在收到接收方确认之前不发送新数据)中为了使接收方区别收到的报文段是重传还是新报文段,只需要用一个比特(值在01之间交替,相邻报文段值不同)标识。这样变成了比特交替协议。

3.3倒计数定时器:接收方的ACKNAK可能丢失,所以发送方用定时器确定重发时间。

3.4流水线可靠传输协议:为了提高效率,发送方不再停等,这需要增加序号的范围。

解决流水线的差错恢复两种基本方法:

3.4.1回退N步(GBN):又称为滑动窗口协议:未确认分组数不能超过N,超过N可能会导致相同序号的报文段传给接收方使接收方不知道它是新的报文段还是重传,窗口长度不大于序号空间的一半。其中原因有发送方和接收方窗口不总是一致。

3.4.1.1发送方:

3.4.1.1.1上层调用发送方:发送方先检查窗口是否已满,如果满了可能缓存这些数据或或使用同步机制(如一个信号量)允许上层在窗口不满时处理这些报文段。

3.4.1.1.2定时器:只有一个定时器,如果收到ACK,但是还有未确认的报文段,重启定时器。

3.4.1.2接收方:

累计确认:接收方只有收到nn以前所有报文段才发送对nACK。发送方只等着序号是当下需要的序号的报文段,收到后发送其ACK,其它失序的都会丢弃。

3.4.2选择重传(SR):与GBN不同的是发送方每个报文段有一个定时器;接收方不累计确认,而是使用缓存接收失序的、未到达过的报文段。

4、TCP:面向连接的运输(总是点对点,不能实现多播)

4.1 TCP连接:

4.1.1三次握手:客户机向服务器发送首部标志位SYN1的特殊报文。同时客户机随机(随机可用于避免攻击)选一个序号client_isn;服务器接到报文段为该TCP连接分配缓存和变量,向客户机发送SYNACK报文段:SYN = 1ACK字段设为client_isn + 1,服务器序号字段server_isn;客户机收到SYNACK后为连接分配缓存和变量,再发送一个报文段:

SYN = 0ACK字段:client_isn + 1。此后报文段SYN都为0

关于为什么要三次握手:

①两次握手:发送方发送的SYN = 1的请求连接报文因为拥堵没有得到ACK,发送方再次发送,接收方收到两次请求,先后建立两个连接,申请两次资源。而发送方只为它最后发送的请求报文的ACK申请资源。接收方有一个连接是无效的、浪费的。

②三次握手保证每次握手出了问题都可以解决(两次握手如上所述一旦第一次握手出了问题,无法解决):

第一次握手出了问题:发送方会重传。接收方收到多个连接请求会申请多次资源,但是连续一段时间没有得到ACK的连接会被断开;

第二次握手出了问题:发送方由于没有收到ACK还是会重传。如果不重传,发送方没有申请资源,而接收方申请的资源在一段时间没有得到ACK的情况下也会被释放;

第三次握手出了问题:发送方发送数据时接收方如果已经释放资源会返回一个RST报文告知连接尚未完成。实际接收方会重传第二次握手的报文(SYN ACK)。

4.1.2四次挥手:连接双方都可以终止连接:客户机发送标志位FIN = 1的报文段,服务器向客户机传回确认报文段。之后服务器发送一次终止报文段(FIN = 1),客户机ACK后等(一般三十秒)准备重传,防止ACK丢失。双方资源释放。

关于为什么要四次挥手:

TCP有个半连接状态。发送方发送FIN报文表示自己没有报文要发送了;接收方收到FIN报文回复ACK后仍可以单向发送报文。接收方没有报文可发时再发送FIN报文,接收方ACK后双方释放资源。

4.1.3如果没有收到的报文段的端口号对应进程不接受连接,发回一个标志位RST = 1的报文段表示无此套接字,不要再发送。

4.2 TCP报文段:MSS(最大报文段长)限制TCP报文段数据字段的长度,基于链路层MTU设置。TCP通常将文件划分成长度为MSS的若干块(最后一块比这小)。

4.2.1源端口号和目的端口号

4.2.2互联网检验和

4.2.3序号字段:该报文段首字节的序号。

4.2.4确认号:主机期待对方传来报文段的序号。比如AB报文段序号98,包含8字节数据。B收到会发送序号为x的报文段,确认号为98 + 8 = 106.A再传给B序号106的报文段。

4.2.5首部长度:因为有选项字段,所以首部长度可变,需要此字段记录。

4.2..6选项字段:可用于协商MSS,或者在告诉网络环境下用作窗口调节因子。还有时间戳选项。

4.2.7标志字段:有SYNFINRST等用于TCP连接控制;还有PSH表示接收方立即将数据传给上层;USG表示包含上层标识为紧急的数据。

4.2.8紧急数据指针字段:指出紧急数据最后一个字节。

4.2.9接收窗口:用于流量控制。

4.2.10数据

4.3 TCP可靠数据传输

4.3.1发送方:

4.3.1.1定时器:只有一个定时器,多个定时器成本太大。定时器时间计算方法:

①计算平均往返时延EstimatedRTT:在某个时刻做一次SampleRTT测量。

EstimatedRTT = x * EstimatedRTT + (1-x) * SimpleRTT。通常x设为1 / 8

②估算RTT偏差DevRTTSampleRTT偏离EstimatedRTT程度):

DevRTT = (1 - y) * DevRTT + y * |SampleRTT - EstimatedRTT|,通常y = 0.25

③设置超时时间:TimeoutInterval = EstimatedRTT  + 4 * DevRTT .

4.3.1.2收到三个冗余ACK或超时就重传。每次重传都将超时间隔加倍。如果收到上层数据或收到ACK就重新计算超时间隔。

4.3.2接收方:采用累计确认,但是失序的报文段会用缓存缓存起来。

4.3.3流量控制服务:消除发送方和接收方缓存溢出的可能。

发送方维持一个接收窗口的变量,由接收方提供(放在报文段接收窗口字段里,标识接收方缓存剩余空间:缓存中数据流最后一字节序号 -接收方进程从缓存读取的数据流最后字节序号)。接收主机缓存空间为0时,发送主机继续发送只有一个字节数据的报文段。接收主机开始清空缓存,确认该报文段,此报文段包含一个非0的接收窗口值。

4.3.4拥塞控制

4.3.4.1拥塞控制原因:①分组到达速率接近链路容量时分组经历巨大的排队时延。

②发送方遇到巨大时延进行不必要的重传会引起路由器利用其链路带宽来转发不必要的分组拷贝。

③当一个分组沿一条路径被丢弃(因为拥堵)时,每个上游路由器用于转发该分组到丢弃该分组的传输容量最终被浪费了。

4.3.4.2拥塞控制方法:有网络层控制的,因特网是在运输层进行控制:

端系统维持一个拥塞窗口的变量CongWin。发送方未被确认的报文段数量小于ConWinRevWinTCP维持一个叫阈值的变量。ConWin小于阈值时每过一个RTT加倍;等于阈值后每过一个RTT增加一个MSS(加性增)。慢启动阶段:起初阈值设置很大,ConWin设置为1MSS,每过一个RTTConWin加倍。这个阶段发送速度很慢,但是加速的快,毕竟指数增长。直到遇到异常,阈值减半:如果是收到三个冗余ACKConWin减半(因为此时和阈值相等,以后加性增);如果发生超时说明网络可能非常拥堵,ConWin设为1MSS(进入慢启动阶段,如果顺利会一直到阈值)。

5UDP:无连接运输:发送报文段之前双方没有握手。

5.1 UDP报文段结构:

5.11源端口号、目的端口号。

5.12长度:包括首部字段在内的报文段长度。

5.13检验和:发送方对报文段所有16byte字的和进行反码运算,溢出都被回卷。不能差错恢复。丢弃受损的报文段或将其交给应用程序并警告。

5.2 UDP存在道理:

5.21分组首部开销小:TCP报文段首部20字节,UDP只有8字节。

5.22无连接状态:连接状态包括接受缓存和发送缓存、拥塞控制参数、序号与确认号。

5.23无需建立连接:没有建立连接的时延。只要应用层把报文穿给UDPUDP将此报文打包成UDP报文段传给网络层。

5.3使用UDP运输层协议的因特网应用:DNSRIP。流式多媒体和因特网电话有时用UDP

 

原创粉丝点击