目录
概要
传输层的作用
传输层的作用
传输层的通信处理
两种传输协议及其区别
端口号
端口号的定义及其识别应用
端口号如何确定
端口号与协议
UDP 用户数据报协议
TCP 传输控制协议
TCP 的特点及其目的
重发超时确定
连接管理（三次握手和四次分手）
发送数据段和提高速度
窗口控制与重发控制
流控制和拥塞控制
提高网络利用率的规范
使用TCP应用
其他传输层协议
UDP-Lite
SCTP
DCCP
TCP和 UDP 的首部格式
UTP首部格式
TCP 首部格式
尾声
概要
这一章我们主要来聊一聊传输层的功能，以及传输层的相关协议，重点是 TCP 和 UDP各自的特点，TCP 的各种控制机制，比方 流量控制 拥塞管理 窗口提速 连接管理等等。
传输层的作用
传输层的作用
前面我们提到过传输层，主要实现源和目标端进程到进程之间的通信。具体是这样，源端主机上开者很多服务和程序，那么这些程序和服务都发到目标端是不是应该找对应的程序接受和处理呢。 好比我qq 和 微信同时聊目标端一位顾客，微信就应该微信接受，QQ 就应该QQ 接受。这就叫保障进程到进程之间的通信。
所以在传输层 通过连接端口号来识别不同的服务，换句话说在应用层的任何服务都会对应添加一个传输层的端口号 来识别不同的服务。 而传输层为了适应不同传输需求 定义了两个不同的协议来分别负责两种类型的服务。也就是我们说的TCP面向连接可靠的传输服务 和 UDP 非连接接的不可靠的传输服务。
传输层的通信处理
那么网络中具体是如何处理通信的呢，在TCP/IP 的互联网世界李，大部分的应用都是以 客户端/服务器方式存在的，客户端就是客户存在方式，请求发起连接，而服务器端则是提供服务的存在，是要处理客户请求的。那也就是说 服务器端必须有程序提前并且一直开启，以便随时接受客户的请求。
这种服务器端的程序，在UNIX 系统（系统不同可能叫法不同）中叫做守护进程，每种服务的守护进程都不同。 比如 web 服务 叫 httpd ssh 服务叫 sshd。但为了更方便管理，unix 系统中并不需要将这些服务的守护进程都开启， 而是启动一个可以代表它们接受客户请求的总守护，inetd (互联网守护进程)，也叫做超级守护进程，
当请求发来是，守护进程可以通过数据包中的端口号来识别应当交给哪个服务程序处理。因为每个端口号对应一个服务且不重复。比方 22 端口 交给 ssh 80 交给 Web 21 交给 ftp
两种传输协议及其区别
传输层最重要的两个协议TCP 和UDP
TCP 传输控制协议 是面向连接的，可靠的流协议。实行顺序控制和重发控制机制。采用TCP 可以保证发送的顺序，接受的完整性。并且具备流控制和拥塞控制 提高网络利用率。
UDP用户数据报协议 不具有可靠的数据传输，很多细微的处理都交给了应用层完成，只保证发送的大小，却不能保证消息一定会到达并接受。
虽然TCP 面向连接有保证的传输，但也是有缺点的 比方连接验证费时，数据传输过程稍有丢失就会重发。而对于一些要求高速传输和实时性较高的通信和广播 就先的力不从心。这是UDP 的优点就显现了出来，UDP 正是去掉了繁杂的验证和保障机制，时效性高，很多组播和广播通信都选择UDP 传输。
端口号
端口号的定义及其识别应用
端口号 （Port Number）好像门牌号，客户端请求可以通过端口号找到对应的服务。对于服务器端，每一个端口对应一个特定的服务 且没有重复。而且我们常见的服务对应的端口是默认不变的。
因此我们反过来可以根据端口号来识别不同的应用。传输层也正是通过端口号来为源端请求数据寻找对应服务程序的。
有时仅仅凭借目标端口还是无法区分服务，比方两个不同的源端主机发送到同一台服务器的web请求，请求的不同页面但端口都是80， 这个时候我们可以通过源端主机端口号来区分。 此外我们还可以根据源IP地址 协议号 等等来区分不同的通信。
所以区分和识别通信其实是可以综合查看源和目标端的IP 地址 端口号 和 协议号来进行的
端口号如何确定
在实际应用中确定端口号有两种方法
标准既定的端口号
这种也叫静态方法，就是每个应用程序都有其指定的端口号，而且不能随意使用任何一个，每个端口对应特定的使用目的或者服务，像 http telnet ssh ftp 等等这些应用都是用固定的端口号，一般不能被别的应用所占用，这些是具有代表性的知名端口号。除此之外，还有一些端口也被正式注册了，但这些是可以用于任何通信用途的。
时序分配法
也叫动态分配法，此时，服务端必须确认监听端口号，而接受服务的客户端不必确认端口号。这种情况下 客户端应用不用自己设置端口，完全交给操作系统进行分配。操作系统可以为每个应用程序分配互不冲突的端口号。
端口号与协议
端口号是由传输层协议处理的，所以即便是TCP 和 UDP 都使用了相同的端口也不会冲突。 应为在网络层通过协议号决定交给TCP 或者UDP 即使端口相同，也是由不同的协议加以处理。
但是那些知名端口 和协议就没关系了，比方 53 端口 无论是TCP还是 UDP都会交给 DNS服务。
下面列出常见的服务和对应的端口号：
TCP 具有代表性的知名端口
| 端口号 | 服务名 | 内容 |
| 7 | echo | Echo |
| 11 | systat | Active Users |
| 13 | daytime | Daytime |
| 20 | ftp-data | File Transfer [Default data] |
| 21 | ftp | File Transfer [Control] |
| 22 | ssh | SSh Remote Login Protocol |
| 23 | telnet | Telnet |
| 25 | smtp | Simple Maiil Transfer Protocol |
| 80 | http | World Wide Web HTTP |
| 101 | hostname | NIC Host Name Server |
| 110 | pop3 | Post Office Protocol -Version 3 |
| 179 | bgp | Border Gateway Agent |
| 443 | https | Http protocol over TLS/SSL |
UDP具有代表性的知名端口
| 端口号 | 服务名 | 内容 |
| 53 | domain | Domain Name Server |
| 69 | tftp | Trivial File Transfer Protocol |
| 123 | ntp | Network Time Protocol |
| 161 | snmp | SNMP |
| 434 | mobileip-agent | Mobile IP Agent |
| 520 | router | RIP |
| 546 | dhcpv6-client | DHCPv6 Client |
| 547 | dhcpv6-server | DHCPv6 Server |
UDP 用户数据报协议
UDP(User Datagram Protocol) 用户数据报协议 。
UDP 不提供复杂的验证 校验和控制机制，利用IP 提供面向无连接的通信服务，可以对发来的数据立即做快速转发。
所以无论拥塞或者丢包 UDP 都不会采取相应的应对措施，不避免拥塞 也不重发数据，甚至不纠正顺序混乱的数据。 如果处理这些只能交给UDP 的上一层应用完成。
虽然如此，由于是面向无连接 可以随时发送，加上UDP 自己简单而高效，所以适用于一下特点的通信
包总量较少的通信（DNS SNMP）
视频 音频等多媒体通信 （即时通信）
限定于LAN 等特定网络中的应用通信
广播通信（广播，多播）
TCP 传输控制协议
TCP(Transmission Control Protocol) 传输控制协议。区别于UDP 它充分实现了数据传输时的各种控制功能，丢包重发 次序混乱重排，拥塞延迟，流量控制，校验数据，等等。 而且TCP 的面向连接的协议，只有确认对方存在可接受数据才发送。可以避免通信资源的浪费。
TCP 的特点及其目的
TCP 协议充分考虑到了数据在传输过程中可能的破坏 丢包 重复 及分片顺序混乱等问题，所以提供了校验和 序列号 确认应答 重发控制 连接管理以及窗口控制等机制。
目的只有一个就是确保对方正确接收到了完整的数据
为了实现这个目的 TCP 采取确认应答的方式，就是当对方收到后返回一个应答确认，表示已收到，然后再接着进行下一步传输。如果在一定时间内对方没有应答，就表示丢失，未到。服务端就重新传输。直到对方确认回复消息。
就好比两个人对话，说完了要看对方的反应 点头或者 嗯 这就表示确认 就是我们网络中的确认应答，如果没有反应或者 提出疑问就是否认应答，需要重新说一遍，传一遍。
正常情况：
数据包丢失的情况
确认应答丢失的情况
重传机制是通过序列号实现的。序列号是按照顺序给发送数据的每一个字节都标号的编号，接收端查询接收数据的TCP 首部序列号和数据的长度，将自己下一步应该收到的序号作为确认应答返给服务器。注意这里还需要数据的长度。 具体如图：
重发超时确定
重发超时时间就是等待确认的时间，如果这个时间内没有收到确认信息就重发。TCP 是如何计算重发时间的呢。根据当时转发的实际情况确认。TCP 在每次发包时都会计算往返的时间，及其偏差，重发超时时间就是比这个总和稍微大一点。在Unix 及windows 系统中 超时都是0.5 为单位，时间是 0.5的倍数。
如果数据重发之后还是收不到确认，就再次重发，等待确认时间将会以2倍 4倍的指数延长。如果多次重发还收不多，就断定网络或对端主机异常，会强制关闭连接。
连接管理（三次握手和四次分手）
TCP 面向连接的传输要求在传输数据之前，也要经过反复的确认才肯开始传输数据。这个叫开始之前的准备工作，形象一点叫连接建立的三次握手程序。
具体我们可以描述为，当客户端向服务器端发送连接请求时，第一个包 TCP 首部中 SYN 标 1 表示要和对方建立连接，是为第一次握手。
对方收到后 会发送 ACK 标 1 的确认，同时还有发送 SYN 为 1 的请求包，要求和客户端建立连接，为了节约时间这本来的两个包合到一起发给对方，表示即确认又请求。视为第二次握手 客户端收到后回复ACK 为1 的确认包，视为第三次握手。至此TCP 连接才正式建立。
那么当数据传输完毕，要断开连接时TCP 也是比较礼貌的。叫四次分手。 具体就是 客户端发送断开请求 TCP 首部的 FIN 位 标 1 表示和对方断开， 对方收到后 回复 ACK 为 1 的确认 。此时如果当前没有数据传输，服务器再向客户端发送 FIN 1 的 断开请求，对方收到后再回复 ACK 为 1 的确认包。至此连接断开。
但是当客户端请求断开，但服务器端发现自己还有数据没有传完的情况下呢，此时服务器会发送确认 ACK 为 1 的数据包给客户端，但服务器此时不会发送 FIN 为1 的断开请求给客户端，这个时候叫半断开。 当服务器数据完全传输完毕后，再向客户端发送断开请求。
具体如图：
发送数据段和提高速度
传输层是以段为单位传输数据的。在三次握手建立连接过程中，对端双方能传输的最大数据长度被确认。也就是 MSS Maximum Segment Size 最大消息长度。在双发建立连接请求时，都在TCP首部写入了 自己的MSS 告知对方自己能够接受的MSS 大小，于是两者之间选择较小的一个值进行传输。
如果仅按照TCP 的段为单位，每一段都需要等待对方确认 效率太低，为了提高效率 人们利用了窗口控制功能，就是以窗口为单位确认，一个窗口里面有若干段，只要在一个窗口内就可以顺序传出，无需等待确认。
这样可以实现段的批量发送和批量确认，有效的提供了速度，但窗口与窗口之间是需要确认等待的。
窗口控制与重发控制
如果在窗口控制的情况下出现段丢失是怎么办的？
首先我们看数据已经传递到，但是确认应答未能返回，这种情况下在窗口控制中是无需重发的。反正已经传到了。那他怎么确定数据传到 只是应答消息未返回，那我们来看数据传不到的情况
因为在确认应答中会提示下一个是怎样序号的数据该传输了，那么如果客户端没有收到数据，窗口中的某段丢失，那么接收端就会多次确认上一个包的信息， 也就是发送端会一直收到同样序号的确认应答，这就说明对方并没有收到新的段。此时我们直接重传确认信息中的下一段就可以了。
流控制和拥塞控制
流控制
TCP 提供了一种可以让发送端根据接收端的实际接收能力控制发送的数据量，叫做流控制，具体是，接收端在TCP 首部的窗口大小中标记上自己可以接受的实际数据大小发送给服务器端。 服务器端根据接收端给的窗口大小实时调整自己的传输量。
如果对方提示满了 就等待。至到收到更新窗口通知，如果一直没有收到呢，服务器端还可以发送一个窗口探测的数据段，探测接收端的接受能力。
拥塞控制
拥塞控制，是为了防止一开始 发送方连续发包导致的网络拥塞，是一种有效的预防机制。具体就是TCP 采用慢启动的算法对发送数据量进行控制。
TCP 在发送端调节所发数据量，定义了一个拥塞窗口，在慢启动时，将拥塞窗口的大小设置为一个数据段，也就是在这个窗口中就发一个数据段。然后每收到一次确认这个窗口加一个数据段，这样慢慢增加发送数据段。
如果遇到重发超时机制，就重新将拥塞窗口 设置未 一个数据段的量发送。
提高网络利用率的规范
Nagle 算法
主要用来提供网络的利用率，即 当数据很少的话，应该发而暂缓发送，延迟等待的一种机制。它给出了两个条件，满足任意一条可以发送，都不满足就暂不发送，当一段时间后再发。
已发送的数据都已经收到确认应答时
可以发送最大段长度MSS 的数据时
延迟确认应答
一般来说考虑到接受端缓存区有限，如果接收端每次都回复确认应答，发送端会收到一个较小窗口，说明接收端缓冲区满。此时发送端就以这个小窗口更小的数据量来发送，这样又降低了网络了利用率。所以人们引入了延迟确认应答的机制。
就是收到数据后并不立即返回确认应答，而是延迟一段时间。应为TCP 采取滑动窗口机制，缺少部分应答无妨。
捎带应答
很多应用层协议规定对端收到消息处理后 要返回一个回执给发送方，很多著名协议 比方 邮件协议 stmp pop3 文件传输 ftp 网页的http 都是如此。 这类回执在TCP 中，连同确认应答可以通过一个包发送，叫做捎带应答，可以使收发的数据量减少。
捎带应答需要启用延迟确认。如果接受数据后立即返回确认应答，是无法实现捎带的。
使用TCP应用
虽然TCP 有很多的机制保证传输，但是这些机制并不是完美无缺的，在很多情况下也是有缺陷困扰的。 所以在应用开发中，我们可以灵活考虑 有些问题可以交给应用层解决，未必非要放到 传输层。 如果应用层可以处理好很多细节的话，UDP 也未必就不是一个更好的选择。
其他传输层协议
传输层难道就只有俩个货在工作嘛 显然不是，只是他们名气最响而已。我们看看其他的。
UDP-Lite
UDP-Lite (Lightweight User Datagram Protocol) 轻量级用户数据报协议。 是扩展UDP机能的一种传输层协议。 因为在UDP 中校验和出现错误的话，接受的包将全部丢弃，但在某些应用中，即便校验错误也不希望吧收到的包丢弃，而如果去掉UDP 的校验不用，又可能发生严重的IP首部错误。
为了解决这个问题 人们改良的UDP 形成 UDP-LIte。 UDP-LIte 提供和UDP 几乎相同的功能，但计算交换和的范围更自由，可以由应用层决定，这个校验的范围是首部 还是首部加数据的某些部分。 这样对于需要校验的部分加校验 。只要不是校验部分的错误 包就不会被丢弃
SCTP
SCTP (Stream Control Transmission Protocol) 流控制传输协议 这个和TCP 一样，提供数据到达与否可靠性检查的传输层协议。 主要特点如下
以消息为单位收发
支持多重宿主
支持多数据流通信
可以定义消息的生存期限
SCTP 主要用于进行通信的应用之间发送的众多小消息， 这些消息被称为 数据块，多个数据块组成一个数据包。 并且STCP 支持多重宿主（就是同一台主机具备多种网络接口）及设定多个IP地址。即便通信过程中IP 地址更换也能继续传输。
DCCP
DCCP(Datagram Congestion Control Protocol) 数据报拥塞控制协议 是一个辅助UDP 的崭新的传输层协议。 因为UDP 本身没有拥塞管理机制，但UDP发送大量数据包时也会拥塞，于是人们制定了 DCCP 规范
特点如下：
与UDP 一样，不能提供发送数据可靠性传输
他面向连接，具备建立连接与断开连接处理
能够根据网络拥塞情况进行控制
为了拥塞控制，接收端收到包后返回确认应答（ACK）
TCP和 UDP 的首部格式
这部分我们聊一聊TCP和UDP 的首部格式
UTP首部格式
UTP 首部格式如图：
源端口号 (Source Port) 表示发送端端口号 16位二进制，可选，因为有时无需设置源端端口号 没有端口号 设为 0
目标端口号 (Destination Port) 接收端端口号 16位二进制
包长度 (Length) 包括了UDP首部长度和数据长度，单位为字节
校验和 (Checksum) 是为了提供可靠的UDP 首部和数据而设计。UDP也有可能不用校验和 此时填入 0 这样协议处理开销更低，从而提高了数据转发率。
TCP 首部格式
UDP首部格式如图：
源端口号 (Source Port) 表示发送端端口号 16位 二进制
目标端口号 (Destination Port) 表示接收端端口号 16位二进制
序列号 (Sequence Number) 长度32位 指发送数据段的位置，每发送一次，就累加 一次该数据字节上的大小。并不是从0 或者 1 开始 而是系统随机数
确认应答号 (Acknowledgement Number) 长度 32位 指下一次应该受到的数据的序列号，是用来确认已收到确认应答号前一位为止的数据。对方收到后认为这个号之前的数据都被正常接受
数据偏移 (Data Offset)
表示所传的数据部分应该从TCP 包的哪个位置开始计算。 也可以看作是TCP 首部的长度。
保留 (Reserved) 作为以后扩展时使用而存在 长度 4位
控制位 (Control Flag) 长度 8位 从左至右 为 CWR ECE URG ACK PSH RST SYN FIN
这些控制位只有值为 1时 有效 各自表示不同的意义
CWR 和 ECE 一起用于IP首部的ECN 字段，值为 1 表示通知对方已将拥塞窗口缩小。
URG 紧急位 为1 时 表示包中需要紧急处理的数据
ACK 确认位 为1 表示确认应答
PSH 推送位 为1 表示需要将收到的数据立刻传给上一层应用。
RST 重置位 为 1 表示 TCP 连接异常终端 所有连接信息初始化 只能重新建立连接开始
SYN 请求位 为 1 表示希望和对方建立连接， 并设置序列号初始值。
FIN 结束位 为 1 表示 希望和对方断开连接。
窗口大小 (Windows Size) 用于通知对方所能接受的数据大小，TCP 不会发送超过此窗口大小的数据，如果设为 0 表示可以发送窗口探测 了解对方具体的窗口大小。
校验和 (Checksum) 和 UDP 一样校验首部和数据部分。 但无法关闭。
紧急指针 (Urgent Pointer) 当URG控制位 为1 时 ，紧急指针才有效，表示所指位置为紧急数据需要紧急传输。
选项 (Options) 用于提高 TCP 的传输性能，
尾声
好 关于 传输层我们就聊这么多了，这章中主要时关于TCP 和 UDP 的相关介绍，重点是TCP的 很多机制比方拥塞控制 窗口提速 重发机制等等 还有连接管理中的三次握手。还有我们列出的知名协议端口号。 其余的UDP 简单了解，传出层的其他协议做到了解就可以了。那么下一章我们来聊一聊路由协议。如果有谬误的地方，希望大家不吝赐教，大家可以留言相互讨论之。感谢！
（内容和图片参考和来源于《图解TCP/IP》 第五版 人民邮电出版社 特表谢意）
