说在前面：这个文章是用于我的个人复习，因此不能保证内容正确。文章内容参考教材《计算机网络自顶向下》以及网络知识，写的会比较杂乱，等有空了再来修改
传输层
应用层<----提供服务—>**
传输层**<—接收服务—>网络层
1，传输层服务，进程到进程通信
寻址：端口号（通过C-S模式）
本地主机：客户，远程主机：服务器
使用IP地址来定义主机
使用端口号来定义进程
端口号：0----65535之间的16位整数
客户端使用临时端口号（客户的生命周期通常很短）
服务端：熟知端口号
端口号范围：
套接字地址：IP地址+端口号=套接字地址
封装与解封装：
封装在发送端发生，当进程有报文要发送：将报文+套接字地址+其他信息发送给传输层，传输层接收数据，加入传输层头部
解封装发生在接收端：报文到达目的传输层，头部被丢弃，传输层将报文—>发送给应用层运行的进程；如果需要响应收到的报文，发送方的套接字地址被发送到进程
多路复用、多路复解
源端的传输层执行复用（多对一）
目的端传输层执行多路复解（一对多）
流量控制
使用2个缓冲区，发送方一个，接收方运输层一个
缓冲区是一组内存单元；发送方缓冲区满，则通知应用层停止传输报文，有空闲了再通知他；接收方满了，通知传输层停止传输，有空闲了再通知一下
差错控制
因为IP层（网络层）是不可靠的，如果应用层要可靠那只能靠传输层了！！！！
差错控制负责：
1，发现丢弃被破坏的分组
2，记录丢失和丢弃的分组并重传
3，识别重复并丢弃
4，缓冲失序分组直到丢失的分组到达
序号，通过序号来辨认是否产生差错
确认：发送消极or积极的信号作为差错控制
接收方可以位每一组正确到达的分组发送一个确认ACK，接收方可以简单地丢弃被破坏的分组。发送方如果使用计时器，就可以发现丢失分组，当一个分组被发送。发送方就开启一个计时器。如果ACK在计时器超时之前没有到达，就重发这个分组。重复的分组可以被接收方默默丢弃。时许的分组既可以被丢弃，也可以存储直到丢失的那个分组到来。（太强了666
流量控制+差错控制：
要求使用2个缓冲区(两个序号，x+y)
发送端：分组准备发送时，我们使用下一个缓冲区空闲位置号码x作为分组的序号；分组被发送，一个分组的备份存储在内存
滑动窗口：0到2^m-1范围内进行线性移动
拥塞控制
第一部分还没有讲述，稍后补
面向连接服务VS无连接
无连接意味着分组之间独立，会发生差错（顺序错误或者丢失）
面向连接，需要进行建立连接（3次握手），可以实现流量控制、差错控制、拥塞控制
二、传输层协议
1，简单协议
2，停止-等待协议：【流量控制】【差错控制】比较低效
发送方和接收方使用大小为1的滑动窗口
发送方发送分组（加入校验和）开启定时器-------->等待接收方的确认
3，回退N帧协议
接到确认之前，可以发很多个分组，但是接收端只能缓冲一个分组，保存分组副本直到确认到达。
（这边序号是模2^m，如果返回一个7，说明前面的都到达了，现在请把7发过来。这边就涉及到一个不够高效的点，比如发了4-13，只有7丢失了，之后的8-13都到达了，但是发送方只能重发7-13，之后接收方丢弃多余的分组。回退N帧就是这么回事。
3，选择性重复协议
选择性地重发丢失的分组。这个是最靠谱的。
主要是设计了接收方的窗口大小为2^(m-1）这样分组可以按照顺序存储，直到有连续的分组出现，把他们发到应用层
（可靠协议从不传递失序的分组）
计时器：选择性重复协议，为每个未完成分组使用一个计时器，当一个计时器终止，只有一个分组被发送。
4，双向协议：捎带
三、UDP用户数据报协议
分组：用户数据报，头部（8字节）+数据
头部：4个字段
源端口号+目的端口号+用户数据报长度（头部+数据的长度）+校验和
服务：
1进程到进程的通信：使用套接字地址
2无连接服务
i.每个用户数据报都是独立的数据报，不同的数据报之间没有关系
ii.不建立连接和连接终止
iii.不进行编号
iv.每个数据要<65507字节（头部8字节，ip头部20字节）
3没有流量控制和差错控制（只有校验和，如果校验不对，就丢弃）没有拥塞控制
4封装和解封装√
4，TCP传输控制协议
终于到TCO啦，是传输层里的扛把子
关键词：
【进程到进程通信】、【面向连接】
1，流传递服务
TCP是一个面向流的协议，设置了【发送】和【接收】的缓冲区（也用于差错、流量控制）
实现：以一字节为存储单元的循环数组
【发送端】：3种类型的存储单元，“空的”“已发送但没有得到确认的”“已发送的”
【接收端】：“空的”“已收到但是还没读到”
全双工通信：数据可以在同一时间双向流动
2，序号系统
TCP头部采用序号和确认号（字节序号，不是段序号
在0到2^32-1之间一个数字作为启示号，比如1057，如果一共有6000个字节要发送，那序号就是1056-7056
此6000字节被分为6段
段1：1057-2057
段2：2058-3057
段3：3058-4057
段4：4058-5057
段5：5058-6057
段6：6058-7057
3，段：头部+数据
头部：20-60字节
源端口地址+目的端口地址（16位+16位）
序号32位，确认号32位，(段的接收方期望从对方接收的字节号）
头部长度4位，保留6位URG，ACK,PSH,RST,SYN,FIN窗口大小16位，校验和16位，紧急指针16位，选项与填充（最多40字节）
4，TCP连接（虚连接）
面向连接过程：连接建立、数据传输、连接终止
三次握手：
服务器告诉它的TCP，已经准备好接收连接–>【被动打开】
紧急数据
TCP 是面向字节流的协议。这就是说，从应用程序到 TCP 的数据被表示成一串字节流。数据 的每一个字节在流中占有一个位置。但是，在某些情况下，应用程序需要发送紧急（urgent）字节， 某些字节需要另一端的应用以特殊方式对待。解决方法是发送一个 URG 标志置位的段。发送应用 程序告诉发送端的 TCP，这块数据是紧急的。发送端 TCP 创建段，并将紧急数据放在段的开始。 段的其余部分可以包括来自缓冲区的普通数据。头部中的紧急指针字段定义了紧急数据的结束（紧 急数据的后一个字节）。例如，如果段序号是 15 000 且紧急指针的值是 200，那么紧急数据的第 一字节是字节 15 000 且后一个字节是 15 200。段中的剩余字节（如果存在的话）是非紧急的。 有一点需要提及，这很重要，那就是 TCP 的紧急数据不是人们所想的优先服务，也不是带外 数据服务。相反，TCP 的紧急模式是一种服务，发送端的应用程序通过这种服务将字节流的某些 部分标记为需要接收端特别对待的字节流。接收端 TCP 将字节（紧急或非紧急）按序传递到应用 程序，但是通知应用程序紧急数据的开始和结束。留给应用程序决定如何处理紧急数据。
连接终止
交换数据双方的任一方（客户或服务器）都可关闭连接，尽管通常情况下是由客户端发起。当 前大多数对连接终止的实现有两个方法：三次握手和带有半关闭选项的四次握手。 三次握手 当前对连接终止的绝大多数实现是三次握手（three-way handshaking），如图 3-49 所示。 1．在正常情况下，在客户进程接收到一个关闭命令后，客户的 TCP 发送第一个段：FIN 段， 即其中的 FIN 标志置位。注意，FIN 段可包含客户机要发送的后数据块，或如图 3-49 所示的只 是控制段。如果它只是控制段，它仅占有一个序号因为它需要被确认。
如果 FIN 段不携带数据，则该段占用一个序号。
2．服务器 TCP 接收到 FIN 段后，通知它的进程，并发送第二个段：FIN + ACK 段，证实它接 收到来自客户端的 FIN 段，同时通告另一端连接关闭。这个段还可以包含来自服务器的后数据 块。如果它不携带数据，则这个段仅占用一个序号。
如果 FIN + ACK 段没有携带数据，则该段仅占用一个序号。
3．客户端的 TCP 发送后一段，即 ACK 段，来证实它接收到来自服务器的 FIN 段。这个段 包含确认号，它是来自服务器的 FIN 段的序号加 1。这个段不携带数据也不占用序号。 半关闭 在 TCP 中，一端可以停止发送数据后，还可以接续接收数据。这就是所谓的半关闭（half-close）。
虽然任一端都可发出半关闭，但通常都是由客户端发起的。当服务器在开始处理之前需要接收到所 有数据，这时就会出现半关闭。例如，排序是一个很好的例子。客户端发送数据给服务器进行排序， 在开始排序之前，服务器需要接收到全部数据。这就是说，客户端发送全部数据之后，它在客户到 服务器方向可关闭连接。但为了返回存储数据，服务器到客户方向必须保持打开。服务器在接收到 数据后还需要时间进行排序；它的向外方向必须保持打开。图 3-50 给出了半关闭的例子。
从客户到服务器的数据传输停止。客户端通过发送 FIN 段实现半关闭连接。服务器通过发送 ACK 段确认半关闭。然而，服务器还可以发送数据。当服务器已经发送完被处理的数据时，它发送一个 FIN 段。该 FIN 段由客户端的 ACK 来确认。 连接半关闭后，数据可以从服务器传送给客户端，而确认可以从客户端传送给服务器。客户不 能再向服务器发送任何数据。 连接重置 在一端的 TCP 可能拒绝连接请求，可能终止已存在的连接，也可能结束空闲连接。所有这些 都通过 RST（重置）标志完成。
扫一扫
301
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
