计算机网络-传输层小结
title: 计算机网络-传输层小结
date: 2020-02-13 13:35:15
tags:
- 传输层
- TCP/UDP协议
categories: - 计算机网络
index_img: /img/default.png
[TOC]
传输层学习笔记
主要内容包括:
- 传输层的功能
- 传输层协议UDP 和 TCP
- 网络安全
- TCP可靠传输的实现
- TCP流量控制
- TCP的拥塞控制
- TCP的传输连接管理
| OSI | DOD | TCP/IP协议集 |
|---|---|---|
| 应用层 | 应用层 | Telent,FTP,SMTP,DNS,HTTP等 |
| 表示层 | 应用层 | |
| 会话层 | 应用层 | |
| 传输层 | 传输层 | TCP,UCP |
| 网络层 | 网络层 | IP,ARP,RARP,ICMP |
| 数据链路层 | 网络接口 | 各种通信网络接口(以太网等)物理网络 |
| 物理层 | 网络接口 |
一、概述
传输层有个协议 TCP 和UDP
TCP (Transmission Control Protocol),传输控制协议
客户端与服务器之间建立会话,将需要传输的文件分段传输,可靠传输、流量控制
UDP(User Data Protocol),用户数据报协议
用户报文协议,一个数据包就能够完成数据通信,不分段,不需要建立会话,不需要流量控制,不是可靠传输
一个数据包最大是 65535(2^16)字节
数据链路层 46-1500 字节
应用层和传输层协议之间的关系

常见的应用层协议使用的端口
| 协议名称 | 端口 |
|---|---|
| Http | TCP + 80 |
| Https | TCP + 443 |
| RDP | TCP + 3389 |
| FTP | TCP + 21 |
| 共享文件夹 | TCP + 445 |
| SMTP | TCP + 25 |
| POP3 | TCP + 110 |
| Telnet | TCP + 23 |
| DNS | UDP + 53 |
服务与应用层之间的关系
- 服务使用TCP或UDP端口侦听客户端请求
- 客户端使用IP地址定位服务器 (使用目标端口 定位服务)
- 可以在服务器网卡上设置只开放必要端口,实现服务器的网络安全
如何查看服务侦听
1 | |
传输层功能 和 端口范围

传输层功能
传输层功能:为应用进程之间提供端到端的逻辑通信
- 传输层还要对收到的报文进行差错检测
- 传输层提供面向连接(TCP)和面向无连接(UDP)的服务
传输层和应用层之间的主要区别
- 网络层 提供主机之间的逻辑通信
- 传输层提供进程之间的逻辑通信

端口 0 ~ 65535
端口用一个 16 位端口号进行标志
端口号只具有本地意义,即端口号只是为了标志本计算机应用层中各个进程。在因特网中不同计算机的相同端口号咯是没有联系的。
端口分类(三类端口)
- 熟知端口 0 ~ 1023
- 登记端口 1024 ~ 49151
- 客户端口 49152 ~ 65535
二、UDP
UDP特点
- UDP是无连接的,发送数据之前不需要建立连接
- UDP使用尽量最大努力交付,不保证可靠交付,同时也不适用拥塞控制
- UDP是面向报文的。UDP没有拥塞控制,适合多媒体通信的要求
- UDP支持一对一,一对多,多对一和多对多的交互通信
- UDP的首部开销小,只有八个字节
UDP首部:首部开销小,只有八个字节


| 首部字段名称 | 描述 |
|---|---|
| 检验和 | UDP检验和计算.png |
| 长度 | UDP首部 + 数据总 长度 |
| 源端口 | |
| 目标端口 | |
| 伪首部(网络层首部的) | 这个是网络层首部信息,不是真的传输层信息,用来计算 检验和 |
三、TCP
TCP 特点和概述
TCP是面向连接的传输层协议
传输之前,需要进行三次握手,确认通畅
每一条TCP连接只能有两个端点(endpoint),每一条TCP连接只能是点对点(一对一)
TCP提供可靠交付服务
TCP提供全双工通信
面向字节流
TCP面向字节流 传输
发送方 和 接收方 建立连接,准备文件
tcp1.png
发送方 将数据分块 缓存到 TCP 缓存,每次缓存大小没有规律

从缓存中取出数据(这里的取出也是没有规律),添加TCP 头封装成数据包
tcp3.png
接收端 将收到的数据放入 TCP缓存中,同时去掉 TCP 头,
按照顺序将发送端分割的数据包组装起来tcp4.png
接收端 从 TCP缓存中读取数据(这里的读取大小也是没有规律,每次读几个不定)
tcp5.png
tcp6.png
TCP的连接
TCP把连接作为最基本的抽象,每一条TCP连接有两个端点
TCP连接的端口不是主机,不是IP地址,不是应用程序,不是传输层的协议端口。
TCP连接的端点叫做 套接字(socket)
套接字:端口号 + IP地址

TCP 报文段的首部格式


| 字段名称 | 描述 |
|---|---|
| 源端口 Source Port | |
| 目的端口 Destination Port | |
| 序号 Sequence number | 如果是第一个 序号为 1,不是第一个序列号为上个数据包的确认号 + 1 |
| 确认号 Acknowledgment number | 告诉发送者 下一个 该发哪一个数据包 |
| 数据偏移Header Length | 标记TCP段的首位长度,在TCP报文段中第几号开始是TCP数据部分,占四个字节,每个字节是0-15,所以数据偏最大是15 * 4 = 60 |
| 保留 | 占6位,保留为今后使用,目前应置为0 |
| CWR(Congestion Window Reduced) | |
| ECN-Echo | |
| URG | 当URG=1,表明紧急指针有效。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据),而不是按原来的排队顺序来传送。发送应用进程告诉发送方的TCP有紧急数据要传送,于是发送方TCP就把紧急数据插入到本报文段数据的最前面,而在紧急数据后面的数据仍是普通数据从发送方TCP缓存中 紧急数据包 相当于插队到第一个位置被发送 |
| ACK | 仅当ACK= 1时确认号字段才有效。当 ACK=0时,确认号无效,TCP规定,在连接建立后所有传送的报文段都必须把ACK置1 |
| PSH Push | PSH=1时,接收方 TCP收到 pSH =1的报文段,就尽快 将数据包从TCP缓存中给应用程序,而不是继续在TCP缓存中排队给应用程序 |
| RST Reset | 当 RST=1,表明 TCP连接出现严重差错(如主机崩溃,浏览器意外关闭),必须释放连接,然后再重新建立运输连接。 RST置1还可以用来拒绝一个非法的报文段或拒绝打开一个连接 RST 也称为 重建位 或 重置位 |
| SYN Synchronization | 在连接建立时用来同步序号当 SYN=1而ACK=0时,表明这是一个连接请求报文段,对方如果同意建立连接则应在响应的报文段中使用SYN=1和ACK=1。因此SYN=1表示这是一个连接请求或连接接收报文, |
| FIN | 用来释放一个连接。当 FIN=1时,表明此报文段的发送方的数据已经发送完毕,并要求释放运输连接。 |
| 窗口 Window size value00 | 占两个字节,窗口值是[0,2 ^16 -1 ]之间的整数,窗口是接收方 TCP缓存的窗口大小。窗口值是 接收方 告诉发送方:从报文段首部中的确认号算起,接收方目前允许对方发送的数据量(以字节为单位),窗口值作为是接收方 让 发送方 设置 其 发送窗口大小的依据,窗口值经常动态变化发送要给报文段,其确认号是 701,窗口字段是1000,这就是告诉发送方,接收方的我接收缓存空间还可以接收1000个字节数据(字节号是701~1700) |
| 检验和 Checksum | 占两个字节,检验和字段检验范围 包括 TCP首部 和 数据两部分。 和 UDP一样,在计算检验和时,要在TCP报文段前面加上 12 字节的伪首部。伪首部结构跟 UDP伪首部一样,把 第四个字段(协议号)中的(UDP协议号)17 改成(TCP协议号)6 |
| 紧急指针Urgent Pointer | 前提是 URG=1,紧急指针才有意义。紧急指针指出了紧急数据的末尾在报文段中的位置。当所有紧急数据被处理完时,TCP就告诉应用程序恢复到正常操作。即使窗口为0也可以发送紧急数据比如 紧急指针是50, 从数据部分开始计算 数据大小为50字节 TCP紧急指针.png |
| 选项(可变长度) | 1. 最大报文段长度 (MSS Maximum Segment Size):每个TCP报文段(数据部分,不包含首部)的最大长度。发送方和接收方协商最大报文段长度2. 窗口扩大选项:为了扩大窗口 3. 时间戳 4. 选择确认(SACK) |
| 填充 | 选项不够四个字节,填充0,凑够32位 |
TCP协议如何实现可靠传输
1. 可靠传输的工作原理(原理)
只要发送端接收不到确认包,就重发数据包
1. 停止等待协议

无差错情况
超时重传
停止等待协议等待时间过程.png
等待时间=分组时间(TD) + 往返时间(RTT) + 接收确认包时间(TA)
当经过 等待时间,没有确认响应,A默认重发数据包
在发送完一个分组后,必须暂时保留已发送的分组副本,分组和确认分组都必须进行编号,超时计时器的重传时间应当比数据在分组传输的平均往返时间更长一点
确认丢失:接收端收到数据后发送的确认包丢失
发送方经过等待时间,重传数据包,接收方丢弃之前的数据包,接收重传数据包
确认迟到:接收端收到数据后发送的确认包迟到(超出等待时间)
发送方经过等待时间,重传数据包,接收方丢弃之间收到的数据包,重传确认包,发送方收到第一次迟到的确认包,不做任何反应

使用上述的确认和重传机制,就可以在不可靠的传输网络上实现可靠的通信,这种可靠传输协议叫做自动重传请求ARQ(Automatic Repeat Request)
ARQ 重传请求是自动进行的,接收方不需要请求 发送方 重传 某个出错的分组
停止等待协议
- 优点 简单
- 缺点 信道利用率低
信道利用率公式:

2. 流水线传输
发送方 连续发送多个分组,不必每次发完一个分组就停下来等待对方确认,由于信道上一直有数据不间断的传送,这种方式获得很高的信道利用率

连续 ARQ协议
发送方维持一个发送窗口,从头开始发送窗口里的数据包,窗口里的数据是可以发送不可以删除,当收到确认后对应的数据包才可以从缓存中删除,窗口向前滑动。




累计确认:表明接收方已经正确接收序号为n的以前且包括n在内的所有分组
2. TCP的可靠传输 (原理应用)
1. 以字节位为单位的滑动窗口





2. 超时重传时间的设置
TCP每发送一个报文段,就对这个报文段设置一次计时器。只要计数器设置的重传时间到但还没有收到确认,就要重传这一段报文段
TCP协议如何实现流量控制
流量控制:让发送方的发送速率不要太快,要让接收方来得及接收。
1. 利用滑动窗口实现流量控制
发送方和接收方建立连接
接收方 设置接收窗口(rwnd)大小,发送方根据接收方的接收窗口设置发送窗口大小。
在发送过程中,接收方根据自己缓存大小能力给发送方发送 接收窗口大小,发送方根据这个进行动态调整
TCP协议如何避免网络拥塞
拥塞控制介绍
出现资源拥塞的条件: 对资源需求的总和 > 可用资源
拥塞控制:是一个全局性的过程,涉及到所有的主机、所以的路由器,以及与降低网络传输性能有关的所有因素。
流量控制:指在给定的发送端 和 接收端 之间的点对点通信量的控制,它所要做的是抑制发送端发送数据的速率,以便使接收端来得及接收。

拥塞控制处理方法
TCP 进行拥塞控制的算法有四种:
- 慢开始
- 拥塞避免
- 快重传
- 快恢复
发送方维持拥塞窗口 cwnd (congestion window)
发送窗口的实际上限值 = Min[rwnd,cwnd]x
1. 慢开始算法的原理

发送方控制拥塞窗口的原则是:
- 只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去。
- 只要网络出现拥塞,拥塞窗口就减小一些,以减少注入到网络中的分组数。
2. 拥塞避免算法
拥塞避免算法思路:让拥塞窗口cwnd缓慢增大,即每经过一个往返世纪那就把发送方的拥塞窗口cwnd加1,而不是加倍,使拥塞窗口cwnd按线性规律缓慢增长。

拥塞避免不是说完全避免了拥塞,而是在拥塞避免阶段把拥塞窗口控制位按现行规律增长,使网络比较不容易出现拥塞。
3. 快重传算法
4. 快恢复
TCP 的传输连接管理 (三次握手)
传输连接有三个阶段:
- 建立连接
- 数据传送
- 连接释放
TCP 连接的建立都是才用客户服务器方式
主动发起连接的应用进程叫做客户(client)
被动等待连接建立的应用进程叫做服务器(server)

1. 建立连接
刚开始两端TCP进程都是 closed(关闭)状态。主机A作为客户端主动打开连接,主机B作为服务器被动打开连接。
一开始,主机B的TCP服务器进程先创建传输控制块 TCB,准备接受客户进程的连接请求。然后服务器进程就处于 LISTEN(收听)状态,等待客户的连接请求,如果有客户请求,作出响应。
主机A的TCP客户进程也是首先创建传输控制模块 TCB,然后在打算建立 TCP连接时,向B发出连接请求报文段,这时首部中的同步位 SYN=1,同时选择一个初始号 seq=x。TCP规定,SYN报文段(即SYN=1的报文段)不能携带数据,但要消耗一个序号,同时TCP客户进程进入SYN-SENT(同步已发送)状态。
主机B收到连接请求报文后,如果同意建立连接,则向A发送确认。在确认报文段中应把SYN位 和 ACK位 都 置1,确认号 是 ACK=x + 1,同时也为自己选择一个初始序号 seq = y。此时,TCP服务器进程进入 SYN-RCVD(同步收到)状态。
TCP客户进程收到 B确认后,还要向B给出确认。确认报文段的ACK置1,确认号ACK=y + 1,而自己的序号 seq=x+1。TCP规定,ACK报文段可以携带数据,但如果不携带数据不消耗序号。这种情况下,一个数据报文段的序号依然是seq=x+1。这时,TCP连接已经建立,客户端A已经进入ESTABLESHED(已建立连接)状态。
当服务器 B TCP进程收到确认后,也进入ESTABLESHED(已建立连接)状态
思考:当客户端A收到服务器B的响应后为什么还要确认?
为了防止已失效的连接请求报文段又传给服务器B
2. 数据传送
3. 连接释放

数据传输结束后,,通信的双方都可释放连接。
- A进程先向TCP发出连接释放报文段,并停止发数据,主动关闭TCP连接。A把连接释放报文段首部的终止控制位(FIN)置1,其序号seq=u(等于前面以传送的数据的最后一个字节序号加一)。这时A进入
FIN-WAIT(终止等待)状态等待 B 的确认。TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。 - B收到连接释放报文段后发出确认,确认号 ack=u+1,而这个报文段自己的序号是v(等于 B 前面已传送的数据最后一个字节序号加1)。然后 B 进入 CLOSE-WAIT(关闭等待)状态。TCP服务器进程 这时通知高层应用进程,因而从 A 到 B 这个方向的连接就释放了。此时,TCP连接处于半关闭(half-close)状态(
即A已经没有数据要发送了,但B如果发送数据,A依然要接收,也就是说从B到A这个方向的连接并没有关闭,并且这种状态维持一段时间) - A 在收到 B的连接释放报文后,必须对此发出确认。把标记字段中的ACK置1,确认号ack=w+1,而自己的序号是 seq=u+1(
TCP 规定 前面发送过的 FIN报文段要消耗一个序号)。然后进入到TIME-WAIT(时间等待)状态。此时TCP连接还没释放掉,必须经过时间等待计时器 (TIME-WAIT timer)设置的时间2MSL后,A才进入CLOSED状态。时间 MSL叫做最长报文段寿命(Maximum Segment Lifetime)
- 本文作者:Jun
- 本文链接:http://mambajun.github.io/2020/02/19/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C-%E4%BC%A0%E8%BE%93%E5%B1%82%E5%B0%8F%E7%BB%93/index.html
- 版权声明:本博客所有文章均采用 BY-NC-SA 许可协议,转载请注明出处!








