第六章传输层 —— TCP/UDP

第六章传输层——TCP/UDP • 6.1 传输层概述 • 网络层实现了网络环境下主机之间传输信息—IP数据报 • 实际中，从应用需要的是应用程序间的有效数据传送。 • 数据传输的端点是应用进程，到达主机是不够的。 • 应用进程可能有多个。应用进程是动态活动的：有产生、活动、消亡； • IP层传输为“尽最大努力的交付服务”，即不提供可靠性保证： • IP报文可能被丢弃（报文头出错、拥塞发生时、生存期为0）； IP报文数据部分不做校验；链路级的差错检测不能涵盖整个传输过程。 IP提供的是无连接的交付服务。 • IP未为应用传输提供流量控制。 • 在网络层需要进行的拥塞控制与发送端有关。

应用层 传输层链路层物理层 Web 网络层 b0 T elne a1 b1 ted IE node2 node4 a2 b2 a0 node1 node3 ftped A B Telnet node5 node6 Node-to-Node Connection node7 ftp End-to-End Connection Station-to-Station Connection B A a0 b0 Process-to-Process Communication IE Web

在TCP/IP环境中传输层需要解决的问题有： • 端—端的传输服务 • 提供有可靠性保证的服务 • 寻址 • 流量控制 • 复用

工作站D 工作站C 工作站B 工作站A IE telnet ftp Web ftp telnet 传输层 20 80 23 163.15.2.1 163.15.2.6 138.42.3.78 144.45.43.2 网络/链路/物理层

工作站D 工作站C 工作站A 工作站B ftp ftp_D ftp_C ftp_B Server 肚块糷硈絬 20 138.42.3.78 163.15.2.6 144.45.43.2 163.15.2.1 163.15.2.1 163.15.2.1

一般对传输层的要求 • 运输层为应用层进行通信的两个进程之间提供一个可靠的端到端的服务。 • 按照OSI模型的描述，传输层与网络层最大的区别是传输层提供进程通信能力。从这个意义上讲，网络通信的最终地址就不仅是主机地址了，还包括可以描述进程的某种标识。 • 在一个网络连接上复用多对进程的通信。 • 消除网络层的不可靠性；

传输实体——完成传输层功能的硬软件； 传输层实体利用网络层提供的服务向高层提供有效、可靠的服务. 传输层提供两种服务:面向连接的传输服务/无连接的传输服务。

6.2 用户数据报协议UDP (User Datagram Protocol) UDP是一种无连接的数据报传递服务，不保证可靠。它跟远程的UDP实体不建立端到端的连接，而只是将数据报送上网络，或者从网上接收数据报。无连接服务是邮政系统服务的抽象，每个分组都携带完整的目的地址，各分组在系统中独立传送。无连接服务不能保证分组的先后顺序，不进行分组出错的恢复与重传，不保证传输的可靠性。

UDP的作用 UDP根据端口号对若干个应用程序进行多路复用，并能利用检验和检查数据的完整性。由于网络通信的最终地址不仅是主机地址，还需包括可以描述进程的某种标识。为此TCP/IP协议提出了协议端口的概念，用于标识通信的进程。

协议端口 • 多数计算机允许同时运行多个应用程序，因此，在一个系统中可能存在多个进程（Process)/任务（Task)/应用程序（Application Program). • 通信的源和目的应该是这些进程。 • 需要考虑的是： • 进程是动态的。 • 进程的变化不便通知远方的进程。 • 实际中常从接收方实现的功能来识别目的，而不需要知道实现这个功能的进程。 • 一个进程完成多个功能时，进程要知道请求方到底要求何种功能的服务

举例1： 有一封信件是发给某大学一位学生的，而此学生正在球场进行足球赛。邮递员是否需要认出这个同学？是否必须在这个时刻把信递交这个同学。解决：邮递员把信投放到这个同学单位信箱中。举例2：外单位需要了解某毕业生在校情况，可发信件到学校人事处（信箱），至于是老张处理该事务还是小李处理，对这个事件无本质的差别。举例3：同一单位需要招聘毕业生，可发信件到学校毕业分配办公室（信箱）。

进程A 进程X 应用层端口1 端口2 端口k UDP层 UDP基于端口的多路复用 IP层 IP层

从某种意义说：协议端口是主机通信的一系列目标点。从某种意义说：协议端口是主机通信的一系列目标点。

UDP数据报（含伪首部）

应用层 端口x 端口y 端口z UDP UDP UDP UDP UDP UDP UDP层 UDP UDP UDP UDP基于端口的多路复用 UDP UDP UDP IP层 IP层

UDP协议实现示意 UDP数据报首部收到UDP数据报的校验和检查

如果找到一个匹配，则把指向该PCB的指针保存在udp _last_inpcb中，高速缓存了最后收到的UDP数据报的PCB

UDP典型应用 • DNS：DNS用的是53端口。域名解析服务。 • snmp：简单网络管理协议，使用161端口，是用来管理网络设备的。 • 聊天软件Oicq ：Oicq的程序既接受服务，又提供服务，这样两个聊天的人才是平等的。oicq用的是无连接的协议，其服务器使用8000端口，侦听是否有信息到来;客户端使用4000端口，向外发送信息。如果上述两个端口正在使用（有很多人同时和几个好友聊天），就顺序往上加。 • TFTP:端口号69 • RPC:端口号111

6.3 传输控制协议TCP（Transmission Control Protocol） TCP协议是TCP/IP协议簇中重要运输层协议。是面向连接的，可提供可靠的、按序传送数据的服务。 TCP提供的连接是双向的，即全双工的。面向连接服务是电话系统服务模式的抽象，即每一次完整的数据传输都要经过建立连接，使用连接，终止连接的过程。其可望具备流量、差错控制，即提供可靠性传输服务。

一、TCP初步特征 面向数据流——计算机系统常用形式，如文件操作。虚电路连接——建立…。解决差错、失序、流量。保证数据正确到达。有缓冲的传输—有序、大小任意的若干数据块，协议分解/合并… 全双工——对一个进程，提供两个独立、流向相反的数据流。 TCP是一种复杂的、提供可靠传输服务的协议。 ——面向连接的、可靠的、端到端的、基于字节流的传输协议。

TCP 服务 TCP 服务应用者应用者网络低层 TCP目标是通过网络低层，为应用层提供可靠的双向数据流传输。要克服网络低层可能出现的错误和实际问题。

可靠的传输 • 滑动窗口 • 流量控制l • 可变滑动窗口 • 慢启动slow start、拥塞避免congestion voidance 等 • 连接的管理 • 建立连接：三次握手 • 释放连接：三次握手 + 定时器

端口/连接/端点 端点（endpoint）—— （host,port）（128.10.2.3,25）连接（connection）——（ endpoint， endpoint）（18.26.0.36, 1069） —（128.10.2.3,25）（128.9.0.32, 1184） —（128.10.2.3,53）（128.2.254.139,1184）—（128.10.2.3,53）应该注意到：一个端口可以被多个连接共享

一方面，一个端口可以存在多个连接；为多个连接服务的程序不需要为每个连接提供不同的端口。一方面，一个端口可以存在多个连接；为多个连接服务的程序不需要为每个连接提供不同的端口。另一方面，在TCP中可以理解为连接是区分通信的识别，端口是连接的一个组成部分。

二、TCP的报文格式

源端口和目的端口：各16位； • 序号和确认号：以字节为单位编号，各32位； • TCP头的长度：4位，长度单位为32位字，包含可选项域； • 6位的保留域； • 6位的标识位：置1表示有效 • URG：和紧急指针配合使用，发送紧急数据； • ACK：确认号是否有效； • PSH：指示发送方和接收方将数据不做缓存，立刻发送或接收； • RST：由于不可恢复的错误重置连接； • SYN：用于连接建立指示； • FIN：用于连接释放指示

TCP采用可变发送窗口的方式进行流量控制。窗口的大小是以字节为单位的。在TCP报文段首部的窗口字段写入的数据就是当前设定的接收窗口数值。发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整自己的接收窗口（可增大或减小），然后告诉对方，使对方的发送和自己的接收窗口一致。

窗口大小：用于基于可变滑动窗口的流控，指示发送方从确认号开始可以再发送窗口大小的字节流；窗口大小：用于基于可变滑动窗口的流控，指示发送方从确认号开始可以再发送窗口大小的字节流； • 校验和：为增加可靠性，对TCP头，数据和伪头计算校验和；

选项 • 长度可变的字段。TCP只规定了一种选项，即最长报文段MSS(Maximum Segment Size)。 • MSS告诉对方的TCP：“我的缓冲区所能接收的报文段的最大长度是MSS”。 • 窗口和MSS的区别：MSS是一个报文的最大长度。而窗口则是所能发送的所有数据总数，它可以是多个报文段，但每个报文段必须满足MSS的限制，同时其数据总和不能超过窗口大小。

三、TCP的连接与状态机 • 要使每一方都能够确知对方的存在。 • 要允许双方协商一些参数（如，最大报文段长度，最大窗口大小，服务质量等）。 • 能够对运输实体资源（如缓冲区大小，连接表中的项目等）进行分配。

主动打开—被动打开 • 在客户机/服务器模式下，连接的建立请求是由客户机发起的，它执行“主动打开”，而服务器执行“被动打开”，并对客户机的连接请求被动响应。 • 在服务器进程的实现中，首先让服务器执行“被动打开”，告诉其TCP要准备接受客户进程的连接请求。然后服务器进程就处于“听(listen)”的状态，不断检测是否有客户进程要发起连接请求。如有，即作出响应。

第一次：主机A的TCP向主机B的TCP发出连接请求报文，其首部中的比特同步SYN置为1，同时选择一个序号x,该序号称为初始序号ISN(Initial Sequence Number)。 • 第二次：主机B的TCP收到连接请求报文后，如同意，则发回确认。在确认报文中将SYN置为1，确认序号为x+1，同时也为自己选择一个序号y。 • 第三次：主机A的TCP收到此报文段后，还要向B给出确认，其确认序号为y+1。 • 然后客户机A就可以通知上层应用进程，连接已经建立。当B收到A的确认后也通知上层应用进程，连接已经建立。 • “三次握手”是由连接双方的TCP完成的，应用程序只要一个简单的connect调用即可。比如执行telnet命令，当出现login时连接已建立，建立的过程TCP协议实体在后台进行。

A.1037>B.135:s 1415531521:1415531521(0) win 4096 <mss 1024> B.135>A.1037 : s 1823083521:1823083521(0) ack 1415531522 win 4096 <mss 1024> A.1037 > B.135 : . ack 1823083522 win 4096

TCP的有限状态机

利用TCP的应用示例 int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CFrameWnd::OnCreate(lpCreateStruct) == -1) return -1; m_pSvrSocket=new CBoxSocket(); if(!m_pSvrSocket->Create(6666)) { AfxMessageBox("Error creating socket!"); delete m_pSvrSocket; m_pSvrSocket=NULL; return -1; } m_pSvrSocket->Listen(5); return 0; } 创建插座

void CBoxSocket::OnAccept(int nErrorCode) { CBoxSocket* pSock=new CBoxSocket(); if(Accept(*pSock)) { ConnectedSockets.AddTail(pSock); m_nCount+=1; } else { AfxMessageBox("Error Accepting!"); delete pSock; } CSocket::OnAccept(nErrorCode); }; 接受请求

void CBoxSocket::OnReceive(int nErrorCode) { TCHAR buff[2048]; int nRead,pos_Temp; nRead=Receive(buff,2048); switch(nRead) { case 0: AfxMessageBox("Close!");Close();break; case SOCKET_ERROR: AfxMessageBox("Error Receiving!"); break; default: buff[nRead]=0; Send(&my_INT[0], 400,0); } CSocket::OnReceive(nErrorCode); } 收发若干字节

四、TCP的流量控制 • TCP采用可变发送窗口的方式进行流量控制。窗口的大小是以字节为单位的。在TCP报文段首部的窗口字段写入的数据就是当前设定的接收窗口数值。 • 发送窗口在连接建立时由双方商定。但在通信的过程中，接收端可根据自己的资源情况，随时动态地调整自己的接收窗口（可增大或减小），然后告诉对方，使对方的发送和自己的接收窗口一致。这是一种由接收端控制发送端的做法

发送端要发送的数据共9个报文段，每个报文段100字节长，而接收端许诺的发送窗口为500字节。发送窗口当前的位置表示有两个报文段（其字节序号为1-200）已经发送过并已收到了接收端的确认。发送端在当前的情况下，可连续发送5个报文段而不必收到确认。假定发送端已发送了两个报文段但未收到确认，那么它还能发送3个报文段。发送端在收到接收端发来的确认后，就可将发送窗口向前移动了。发送端要发送的数据共9个报文段，每个报文段100字节长，而接收端许诺的发送窗口为500字节。发送窗口当前的位置表示有两个报文段（其字节序号为1-200）已经发送过并已收到了接收端的确认。发送端在当前的情况下，可连续发送5个报文段而不必收到确认。假定发送端已发送了两个报文段但未收到确认，那么它还能发送3个报文段。发送端在收到接收端发来的确认后，就可将发送窗口向前移动了。

期望接收201 201重发

期望接收序列2048 W大小2048

MSS的问题 • 如果太小，则网络的利用率低，比如一次一个字节，利用率只有1/41。 • 如果太大，超过了路径MTU，将导致该报文段在IP层会被分成多个IP数据包，如果某个包发生错误，整个都要重传，这些都会使开销增大。 • 原则：MSS应尽可能大，只要在IP层传输时不需再分片就行。 • 由于双方都有MSS，传送时取较小者。如果主机未填写该项，则MSS默认值是536字节的净负荷，因此在Internet上的主机都应能接受的报文段长度为536+20=556字节。

TCP发报文的时机 • 汇集到MSS数量的字节 • 发送端应用程序指明要发送（PUSH） • 发送计时器时间到问题：当用户打一字符，就可能导致发送一个TCP报文。 1+20（TCP首部）+20（IP首部）=41字节响应也要 40字节。解决办法：推迟发送，捎带应答

Nagle算法 • 若数据是逐个字节地到达发送端，那么发送端不是逐个字节的发送数据，而是先将第一个字符发送出去，将后面到达的字符都缓存起来。当收到对第一个字符的确认后，再将缓冲区中的所有字符装成一个报文段发送出去，同时继续对到达的字符进行缓存。只有在收到确认后才继续发送下一个报文段。 • 当字符到达较快而网络速度较慢时，用这样的方法可明显地减少所用的网络带宽。算法还规定，当到达的字符已达窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。 • 在实时性要求较高的情况下不宜采用Nagle算法：例如在Internet 上使用X-window，要将鼠标移动的信息传到远地主机。若采用Nagle算法会使用户感到无法忍受。

糊涂窗口综合症 • 描述：接收端的缓冲区已满，而交互式的应用进程一次只从缓冲区中读取一个字符（这样就在缓冲区产生1个字节的空位子），然后向发送端发送确认，并通知窗口大小为1个字符（但发送的数据报是40字节长），接着发送端又发来1个字符（但发来的数据报是41字节长）。接收端发回确认，仍然通知窗口为1个字节。这样下去就使网络的效率很低。 • 解决办法：让接收端等待一段时间，使得或者缓冲区已能有足够的空间容纳一个最长报文段，或者缓冲区已有一半的空间处于空的状态。只要出现这两种中的一种，就发出确认报文，并向发送端通知当前的窗口大小。此外，发送端也不要发送太小的报文段，而是将数据积累成足够大的报文段，或达到接收端缓冲区的空间的一半大小。

第六章 传输层 —— TCP/UDP