Linux随笔8-TCP/IP以及UDP相关

Linux随笔8-TCP/IP以及UDP相关

本篇将会从以下三个方面入手

1. 简述osi七层模型和TCP/IP五层模型
2. 总结描述TCP三次握手四次挥手
3. 描述TCP和UDP区别

1. OSI参考模型与TCP/IP模型

本篇将会详细解释OSI参考模型与TCP/IP模型之间的相似点以及差异的地方。初次之外，也会解释TCP/IP的初始的4层模型以及更新后的5层模型之间的差异。

1.1. OSI模型 vs TCP/IP模型（哪一个更好，以及为什么使用TCP/IP模型替代OSI参考模型）

无论是TCP/IP还是OSI，它们都是网络参考模型。两个模型的开发都是开始自1970年代，并且都是在1980年代公布的。在1990年代，厂商要么在他们的产品中支持这两种模型之一或者两者都支持。到1990年代末期，TCP/IP模型变成了厂商们的通用选择而不再采用OSI模型，因为OSI模型相比于TCP/IP模型而言，由更漫长的正式标准化流程。到2000年代，占主导地位的一些厂商放弃了它们自己专有的一些网络模型而转而采用TCP/IP模型。现如今，世界上的计算机只使用一种网络模型，那就是TCP/IP模型。

1.2. 为什么在网络课程中还要教授OSI模型呢？

就解释以及文档方面而言，TCP/IP模型并不能与OSI模型相比肩。OSI模型在计算机网络世界中是一个被很好解释并且形成了完备文档的模型。它不仅用一种易于理解而且易于记忆的方式描述了一些复杂的网络概念、协议以及一些术语。

由于TCP/IP以及OSI模型的创建都是出自相同的目标，它们都采用了相同的开放标准协议集合，也都以相似的方式描述了一些网络概念。通过学习一个模型，就可以很容易的学习另一个模型了。

出于这个原因，即便OSI模型不再被硬件厂商支持以及使用了，但是几乎在所有的网络课上仍然会教授OSI参考模型。一旦学生学会了OSI模型，他们就被引入到了TCP/IP模型中。因为他们已经从OSI模型中学到了基础的主题以及分层方法，所以学习TCP/IP模型对于他们来说就变得很简单了。

所以这篇文章也会遵循相同的方法，前两篇会详细解释OSI模型以及它的分层结构。这篇将会介绍TCP/IP模型以及OSI模型之间的差异以及相似之处，下一篇将会介绍TCP/IP模型以及它的各个分层。上述提及的除了本篇之外的其他几篇链接如下：

• OSI模型的优势以及基本目的解析

  这篇文章是这个系列的第一篇，介绍了创建OSI参考模型的原因以及其优势。

• OSI 7层模型的示例解释

  这篇文章是这个系列的第二篇，详细介绍了OSI参考模型的7层。

• 解析TCP/IP参考模型

  这篇文章是这个系列的第四篇，详细介绍了TCP/IP的5层模型。

• 解析数据封装以及解封装的过程

  这篇文章是这个系列的第五篇，它解释了数据在通过各层的时候是如何被封装以及被解封装的。

1.3. TCP/IP模型与OSI参考模型之间的相似之处

• 两者都是逻辑层面的模型
• 两者都定义了网络标准
• 两者都为创建和实现网络标准以及设备提供了框架
• 两者都将网络通讯过程进行了分层拆分
• 在两个模型中，在单层中定义特定功能，并且只为该功能设置标准
• 两者都允许制造商用于制造设备以及网络组件，并且这些组件和设备可以与其他制造商采用这两种模型制造的设备之共存并且一起工作
• 两者都通过将复杂功能拆分为简单组件从而简化了问题分析和解决过程
• 对于已经被定义的标准和协议，两者都是采用了引用的方式，而不是再重新定义。比如在这两个模型创建之前，IEEE已经定义了以太网标准（Ethernet standards）。所以两者都没有重新定义以太网标准，而是直接使用了IEEE定义的以太网标准。

1.4. OSI参考模型与TCP/IP模型之间的差异

• OSI分层模型中分了7层；而TCP/IP模型中分了4层
• OSI分层模型已经不再被使用了；而TCP/IP模型仍然在计算机网络中被使用
• 为了定义上层的功能，OSI参考模型使用了3个分隔的层（即应用层、表示层和会话层）；而TCP/IP模型则使用了1层（即应用层）
• 类似于上层功能，OSI使用了2个分隔的层（物理层和数据链路层）来定义底层的功能；而TCP/IP模型则使用了1层（即链路层）定义相同的功能
• 为了定义路由协议和标准，OSI模型使用网络层（Network Layer）；而TCP/IP模型则使用了互联网层（Internet Layer）
• 相比于TCP/IP模型，OSI参考模型对于模型中所用的协议、标准有完备详细的文档和解释

1.5. TCP/IP的初始版模型以及更新版模型之间的差异

我们现如今所用的TCP/IP模型与最初的TCP/IP模型有细微的差别。起初的TCP/IP模型有4层；而更新版的TCP/IP模型有5层。

初始版的TCP/IP模型使用1层（即链路层）来定义负责数据传输的功能和组件。更新版的TCP/IP模型使用了2层（即数据链路层和物理层）。

更新版模型将初始版基于功能的链路层进行了拆分。分别拆分成了直接与物理传输相关的功能和间接与物理传输相关的功能，前者对应于物理层，后者对应于数据链路层。

在更新版的模型中，互联网层（Internet Layer）被更改为网络层（Network Layer）。

下图对比了OSI参考模型与初始版TCP/IP模型和更新版TCP/IP模型：

无论你先学习哪个模型，只要你学过了一个模型，那么就很容易与另一个模型进行关联。在通常的对比中，除了应用层之外，更新版的TCP/IP模型或多或少的更类似于OSI参考模型。出于学习的目的，你可以将TCP/IP模型的应用层认为是做了OSI模型的最上面3层（应用层、表示层和会话层）的事情。

上述就是本篇文章的所有内容了，在本系列的下一篇文章中，将会详细介绍TCP/IP模型以及他的各个分层。如果你喜欢这个系列的文章，请不要忘记将它通过你最喜欢的社交媒体分享给你的朋友。

本部分内容原文：similarities-and-differences-between-osi-and-tcp-ip-model

2. TCP的三次握手建立连接以及四次挥手断开连接

2.1. TCP数据段构成

上图是TCP协议报文的数据段，每一行由32位组成。关于每一部分的含义解释如下：

• Source Port, Destination Port：即源端口和目标端口。指定计算机上的进程所占用的端口，每个端口只能被一个进程占用，具有排他性。源端口表示发送该数据包的进程所占用的端口；目标端口表示这个数据包要发送给目标进程所占用的端口号。由于源端口和目标端口各占16位，所以可以推算端口个数为2^16次方个，即65536个。通过源端口和目标端口，以及IP首部中的源IP地址和目标IP地址，就可以唯一确定一个TCP连接。IP地址和端口号可以确定一个套接字（socket）。
• Sequence Number：即顺序号。表示发送端向接收端发送的数据字节流的第一个数据字节的编号。占32位，当该序号到达2^32-1时，又会从0开始进行编号，所以顺序号的有效范围是0-2^32-1，并在这个范围内循环。
• Acknowledgement Number：即确认号。表示接收方期望发送方发送的下一个报文数据字节流的第一个字节的编号。
• Data Offset：即数据偏移量。表示TCP报文段的首部长度，共4位，由于TCP首部包含一个可变长度的选项，所以需要用这个数据偏移量来指定数据字节流的起始处位于TCP报文起始处往后多少个字节的位置。共占用4位，由于该字段的单位是32位（即4个字节的计算单位），而4位2进制数转换为10进制数最大位15，所以数据偏移也就是在TCP首部最大60字节。
• URG：表示本报文发送的数据字节流中是否包含紧急数据。后面的紧急指针（Urgent Pointer）只有在URG=1的时候才有效。
• ACK：表示前面的确认号字段是否有效，只有当ACK=1的时候，前面的确认号字段才有效。TCP协议规定，当TCP连接建立起来之后，该标记必须为1，并且将带ACK标记的报文称为确认报文段。
• PSH：表示提醒接收端进程应该立即将数据从TCP缓冲区中读取出来，即刷新TCP缓冲区，以便为后续的数据字节流的接收提供缓冲区空间。如果该标记为1，则表示接收方应该立即把接收到的数据字节流提交给上层进程，而不是存放在缓冲区中。如果上层进程未将接收到的数据读取出来，那么就将会一直停留在TCP接收缓冲区中。
• RST：如果接收到一个该标记为1的报文，要么说明这个TCP连接出现了严重错误，必须释放连接，并重新建立连接；要么说明上次发送的数据存在问题，带该标记的报文被称为复位报文段。
• SYN：同步序号，在建立连接时使用。当SYN=1，ACK=0时，表示这是一个请求建立连接的报文；当SYN=1，ACK=1时，表示对方同意建立连接。所以，当该标记为1的时候，表示请求建立连接或者同意建立连接。只有在TCP连接的前两次握手报文中，才会将SYN置为1，带SYN标记的报文被称为同步报文。
• FIN：该位为1表示发送端完成了数据发送的任务，通知接收方本端要关闭连接了。带FIN标记的报文被称为结束报文。
• Window：窗口大小，单位为字节数，起始于确认号字段指明的值，这个值是接收端期望接收的值。窗口大小占用16位，所以窗口大小最大位65535字节。表示允许对方发送的数据量。
• Checksum：即校验和，覆盖了整个TCP报文段（TCP首部以及TCP数据），校验和由发送方计算和存储，接收端在接收到该TCP报文的时候会对接收的报文进行验证，看验证结果是否与报文中记录的校验和一致。
• Urgent Pointer：即紧急指针，是一个正数偏移量。该字段的值与顺序号字段的值相加表示紧急数据最后一个字节的序号。只有在URG字段为1的时候，该字段才有效。
• Options：表示选项，最常用的是MSS（Maximum Segment Size），即最长报文大小。每个连接方通常在通信的第一个报文中指定这个选项，它指定了本端所能接收的最大长度的报文段。

2.2. TCP的3次握手建立连接

TCP协议通过3次握手的方法建立TCP/IP连接，3次握手通常指的是“SYN-SYN-ACK”的过程（SYN标记是Synchronize的大写字母形式的缩写，ACK标记则是Acknowledge的大写字母形式的缩写），更精确的标记信号形式为“SYN，SYN-ACK，ACK”。两台通信的计算机之间需要传递上述的报文消息来建立TCP会话连接。在两台计算机传输数据之前（SSH数据、HTTP数据等），3次握手机制允许通讯双方在网络上通过TCP套接字协商参数尝试进行通信。

3次握手过程的设计也可以是双方开始并协商各自的TCP套接字连接。也可以通过多路复用在单一物理网络接口中同步传递多个TCP数据流。

2.2.1. 3次握手过程

下图是简化了的3次握手过程，是将下图中左边的计算机的数据包投递到右边的计算机。

message transmit	dynamic image

上述过程中，发送端向接收端发送"SYN=1"的TCP报文，就像在一个人跟另一个人说，在吗？我想跟你谈恋爱。接收端收到该报文后，会回应一个"SYN=1, ACK=1"的报文，就像在说，我在，我同意跟你谈恋爱。发送端接收到对方发送的"SYN=1, ACK=1"的报文后，回应一个"ACK=1"的报文，就像在说，好的，现在咱们是男女朋友关系了。至此，TCP通信的3次握手建立连接的过程就完成了。

下图是3次握手期间双方之间状态转换的过程。
上述过程中，客户端和服务器端的起始状态均为CLOSED，即未曾建立TCP连接。此时服务器端处于被动打开的状态，监听着本地的某个端口，等待客户端的连接请求；客户端此时处于主动打开的状态，并且向服务器端发送了一个"SYN=1"的报文，随后客户端的状态从CLOSED状态切换为SYN-SENT状态，即同步报文发送完成。服务器端收到客户端发送的"SYN=1"的报文之后，服务器端的状态从LISTEN切换未SYN-RECEIVED状态，即同步报文接收完成，与此同时，服务器端会向客户端回应一个"SYN=1,ACK=1"的报文。客户端在收到上述的报文之后，会给服务器端回应一个"ACK=1"的应答报文，并随后将其状态从SYN-SENT切换为ESTABLISHED状态。服务器端在收到来自客户端的应答报文之后，其状态也会从SYN-RECEIVED状态切换为ESTABLISHED状态。至此，客户端到服务器端的3次握手TCP连接就建立起来了。

2.3. TCP的4次挥手断开连接

TCP使用4次挥手（从1到2的握手）来结束已经建立的TCP连接。具体过程如下图所示：
此时由于是已经建立连接的状态，所以服务器端和客户端的状态都是ESTABLISHED。此时客户端收到来自应用程序进程的关闭TCP连接的信号，然后给服务器端发送"FIN=1"的结束报文，并且将客户端的状态从ESTABLISHED切换为FIN-WAIT1这个状态。服务器端在接收到客户端的上述报文之后，会向客户端回应一个"ACK=1"的应答报文，并且告诉本地监听该端口的应用程序关闭TCP连接，同时将服务器的状态从ESTABLISHED切换为CLOSE-WAIT状态，并且等待应用程序的响应。客户端在接收到服务器端发送的上述报文之后，将其状态从FIN-WAIT1状态切换为FIN-WAIT2的状态，并且等待服务器端发送结束报文。此时服务器端的应用程序已经准备好关闭这个TCP连接了，服务器端会向客户端发送一个"FIN=1"的结束报文，并将服务器的状态从CLOSE-WAIT状态切换为LAST-ACK状态，同时等待客户端的应答报文。客户端在收到服务器端发送的上述报文之后，会给服务器端回应一个"ACK=1"的应答报文，并将客户端的状态从FIN-WAIT2切换为TIME-WAIT状态当等待了2倍的MSL（Maximum Segment Life）时间之后，客户端关闭这个TCP连接，此时客户端的状态从TIME-WAIT切换为CLOSED状态。而服务器端在收到客户端发送的上述应答报文之后，也会将这个TCP连接关闭，于此同时，服务器端的状态从LAST-ACK切换为CLOSED状态。

至此，TCP的4次挥手断开连接的过程就完成了。

其实上述的4次挥手过程是理想情况下的断开连接的状态，实际上可能并不会这样，比如突然的掉电关机、进程被杀掉等等，都不会出现上述的4次挥手断开连接的过程，或者无法正常完成上述的4次挥手断开连接的过程。

本部分内容原文：Understanding of TCP three-way handshake and four waves

本部分内容并未完全遵照原文，有删改。上述文章应该不是英语为母语工程师写的，夹杂着不少语法不合理的地方，并不通顺，但是这几张图是很好的诠释了这个过程，所以仍然引用了这篇文章，并且加上了自己的理解，于是形成了上文。

3. TCP与UDP的区别

3.1. TCP对比UDP

对于那些要求可靠有序的数据包传递的应用程序，TCP协议就满足了这样的需求。它支持错误检测、错误重传以及应答机制。TCP协议会检测数据完整性。

另一些应用可能并不在意传输过程中是否存在丢包的现象，数据包是否被接受到也并不在意。这类应用就可以采用UDP协议，可以提高传输效率，降低数据包校验、检查之类的网络开销。

典型的TCP应用包括电子邮件、web浏览器；典型的UDP应用包括IP音频、音乐流媒体等。

TCP协议严格用于点到点的单播传输场景；而UDP则是应用于多播（组播）以及广播场景，当然，也可以用于单播的通信场景。如下图所示：
#### 3.1.1. TCP和UDP的报文头

TCP和UDP的报文头是在传输层附加到数据消息上的内容，包括源端口、目标端口等信息。由于UDP的简单传输，且是面向无连接的，所以其报文头也相对更简单。而TCP由于支持错误重传、拥塞控制等机制，所以其报文头也更加复杂，在传输过程中，这部分报文头会占用一部分网络带宽，所以传输相同数据量的前提下，TCP比UDP所需要的带宽更多。两种协议的报文头如下所示：
关于这两种协议的更详细的解释，参见如下：

For more information on TCP:
http://en.wikipedia.org/wiki/Transmission_Control_Protocol
For more information on UDP:
http://en.wikipedia.org/wiki/User_Datagram_Protocol

本部分文章原文连接：TCP vs. UDP

3.2. TCP与UDP：它们之间的差别是什么

3.2.1. 什么是TCP

TCP/IP用于帮助你决定在特定的计算机之间如何通过网络进行连接，并且在它们之间如何进行数据传输。当有多个计算机网络被连接的时候，它可以帮助你创建虚拟网络。

TCP/IP全称为Transmission Control Protocol/Internet Protocol，即传输控制协议/互联网协议。其是为了提高在不可靠网络中传输可靠性以及端到端的字节流数据传输为目的而特别设计的模型。

3.2.2. 什么是UDP

UDP是面向数据报的协议，它大多用于广播以及组播（多播）的场景中进行网络数据传输。UDP的全称是User Datagram Protocol，即用户数据报协议。一个数据报就是包交换网络中的一个传输单元。UDP协议的工作方式类似于TCP，但是它丢弃了TCP协议的错误检查机制。

3.2.3. 关键差别

• TCP是面向连接的协议；而UDP则是无连接的协议
• TCP的数据传输速度略慢；而UDP的传输速度更快一些
• TCP使用类似"SYN, SYN-ACK, ACK"的3次握手方式建立连接；而UDP并不使用握手协议
• TCP支持错误检查以及错误恢复；而UDP虽然也会进行数据校验，但是它会丢弃错误的数据包
• TCP有应答数据段；UDP没有应答数据段
• TCP是重量级协议；UDP是轻量级协议

3.2.4. TCP怎样工作

TCP连接是通过3次握手的方式建立起来的。这个过程是一个发起并确认连接的过程。一旦连接被建立起来，就会开始进行数据传输；当传输过程结束，就会通过关闭建立的虚拟环路的形式结束连接。

3.2.5. UDP怎样工作

UDP使用了一种简单的、没有握手对话过程的通信方式，所以其并不保证数据的有序性、可靠性以及数据完整性。UDP假定错误检查以及纠正并不重要，或者是在应用层进行错误检查以及纠正的实现，以此来避免网络接口级别的数据传输过程中的开销。一般用在广播或者组播（多播）的场景中。

3.2.6. TCP和UDP的特性

此处，是TCP的一些重要特性：

• 投递应答数据段
• 错误重传
• 当网络出现拥塞的时候支持数据延迟传送
• 易错检测

此处，是UDP的一些重要特性：

• 支持能够容忍丢包情况的带宽密集型应用
• 低延迟
• 可以发送大量数据包
• 存在数据丢失的可能性
• 允许小的事务（比如DNS查询）

3.2.7. TCP和UDP之间的差别

此处是TCP和UDP之间的差异比较。具体如下表：

TCP	UDP
面向连接的协议	无连接的协议
TCP以字节流的方式读取数据，并且消息的投递是分段进行的	UDP消息中包含了需要一个接一个被投递的数据包。其也支持在接收的时候检查数据完整性
TCP消息可以跨网络从一台计算机传递到另一台计算机	UDP不是基于连接的，所以程序可以发送很多数据包给其他计算机
TCP会按照特定的顺序重新安排数据包	UDP协议没有固定的数据包顺序，因为所有的数据包都是彼此独立的
TCP的传输速度略慢	UDP传输速度更快但是不支持错误恢复
TCP协议头占20个字节	UDP协议头占8个字节
TCP是重量级协议，TCP协议在开始传递用户数据之前需要三个数据包来设置套接字连接（即3次握手）	UDP是轻量级协议，没有追踪连接，消息也没有顺序
TCP会进行错误检查并支持错误恢复（重传）	UDP也支持错误检查，但是会丢弃有错误的数据包
包含应答段	没有应答段
使用握手协议，即"SYN, SYN-ACK, ACK"	无握手协议（无连接的协议）
TCP是可靠的，其可以确保数据被投递到目标路由器	UDP无法保证数据包被投递到目标路由器
TCP支持拓展错误检查机制，因为它提供了流控和应答段	UDP只有单一的错误检查机制，只是用于进行校验和计算

3.2.8. TCP的优势

• 帮助你在不同类型的计算机之间建立/设置连接
• 可以独立于操作系统进行操作
• 支持很多路由协议
• 可以使不同组织之间通过互联网进行工作
• TCP/IP模型是具有高可扩展性的Client-Server架构

3.2.9. UDP的优势

• 它并不会将你限制为基于连接的通信模型；这就是为什么在采用UDP协议的分布式应用中启动延迟如此之低的原因
• UDP的数据包接收端是无管理的
• UDP通常用于广播或者多播（组播）的场景中
• 可能会有丢包的情况
• 小的事务（DNS查询）
• 适用于能够容忍丢包的带宽密集型应用

3.2.10. TCP的劣势

• 在显式确认所有传输中的数据完成之前并不会结束传输
• 无法在广播或者多播（组播）的场景中应用
• TCP没有块边界（block boundary），需要你自己创建
• TCP可能提供了很多你并不需要的特性，所以可能会浪费带宽、时间或者精力
• 要替换TCP/IP协议并不容易
• 在服务、接口以及协议之间并没有很清楚的分隔

3.2.11. UDP的劣势

• 在UDP协议中，数据包可能被丢失或者被传递两次，并且传递的数据包是无序的，而且没有任何指示
• 如果发生冲突，由于路由器是不关心UDP数据包的，所以就无法被传输（Routers are quite careless with UDP, so they never retransmit it if it collides.）
• UDP不支持拥塞控制、流控，所以这些工作需要在应用层实现
• UDP可能会丢包

3.2.12. 何时应该使用TCP，何时应该使用UDP

• TCP通常情况下是理想选择，即便有额外的开销，绝大部分开销实在连接过程中，应用程序可以将连接保持任意长的时间
• UDP很适合于多媒体领域，比如IP电话等语音服务
• 对于连接过程中偶发的延迟可以接受的话，可以在客户端和服务器端之间使用TCP套接字进行数据包的发送和接收
• 如果客户端和服务器端的延迟是不可接受的，并且客户端和服务器端是分别进行数据包发送的，那么就需要使用UDP协议（比如多媒体游戏）

本部分文章原文链接：TCP vs UDP: What’s the Difference?

上述文章仅作学习交流之用，勿做他用，如果侵权请联系告知删除