###1、传输层概述
实际上，传输层的功能很简单，它主要负责向应用层提供端到端之间的通信服务，

通俗的讲，两个主机通讯，也就是应用层上的进程之间的通信，也就是转换为进程和进程之间的通信了，

我们之前学到网络层，IP协议能将分组准确的发送到目的主机，但是停留在网络层，

并不知道要怎么交给我们的主机应用进程，通过前面的学习，我们学习有mac地址，通过mac地址能找到同一个网络下主机，

有IP地址，通过ip地址能找到不同网络下的网络，结合mac地址就能找到对应主机，

那么怎么找到主机应用进程呢，肯定也有一个东西来标识它，那就是我们常说的端口号了。

端口，占有16位，其大小也就有65536个，是从0~65535.也就是一台计算机有65535个端口，

主机之间的通讯，也就是应用进程之间的通讯，都要依靠端口，一个进程对应一个端口，进程A和进程B通信，

进程A分到的端口为60000，进程B分到的端口为60001，

进程A通过端口60000发送数据给进程B，就知道要交给60001端口，也就到了进程B中 ，这样就达到了通信的目的。

传输层中的65536个端口，主要可以分为三类：熟知端口、登记端口和客户端端口。

1、熟知端口：

0-1023， 也就是一些固定的端口号，比如http使用的80端口，意思就是在访问网址时，

我们访问服务器的端口就是80，然后服务器那边传网页的数据给我们。

2、登记端口：

1024-49151，比如微软开发了一个系统应用，该应用在通讯或使用时，需要使用到xxx端口，

那么就要去登记一下这个端口，以免有别人公司的应用使用同一个端口号，

例如，windows系统中的3389端口，就是用来实现远程连接的，就固定了这台计算机如果要使用远程连接服务，

就打开3389端口，别人就能使用远程连接连你了，默认是不打开的。

还有3306，这是Mysql数据库中默认的端口号，如果被占用之后，安装Mysql就需要修改端口了。

3、客户端端口：

49152-65535，一般我们使用某个软件，比如QQ，等其他服务，随机拿这个范围内的端口，

而不是去拿前面哪些固定的，拿到等通讯结束后，就会释放该端口。

所以在给传输层创建端口号前，应该先查看当前服务器，除了0-1023端口之外，还使用了哪一些端口，以免产生不必要的冲突。

知道了端口是什么？

运输层具体做了什么事情呢？

运输层就是将两个端口连起来通信的介质，不然光知道两个端口有什么用，怎么通信的，

还是要靠运输层来做这个事情，其中重要的就是靠两个协议，UDP和TCP协议。

下面我们就来学习下UDP和TCP协议的具体内容和区别。

###2、UPD协议
UPD是一组简单的、面向用户数据报文的传输层协议。

UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。

由于UDP在传输数据报文前，不用在客户和服务器之间建立一个连接，并且没有超时重发等机制，故而传输速度很快。

无连接：意思就是在通讯之前不需要建立连接，直接传输数据。

不可靠：是将数据报文的分组从一台主机发送到另一台主机，但并不保证数据报能够到达另一端，任何必须的可靠性都由应用程序提供。

在 UDP 情况下，虽然可以确保发送消息的大小，却不能保证消息一定会达到目的端。

没有超时和重传功能，当 UDP 数据封装到 IP 数据报传输时，如果丢失，会发送一个 ICMP 差错报文给源主机。

即使出现网络阻塞情况，UDP 也无法进行流量控制。

此外，传输途中即使出现丢包，UDP 也不负责重发，甚至当出现包的到达顺序杂乱也纠正不了。

###3、TCP协议
TCP是一组相较复杂的、面向连接传输控制的传输层协议。

提供的是面向连接、可靠的字节流服务。

当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。

TCP提供超时重发，丢弃重复数据，检验数据，流量控制，拥塞控制等功能，保证数据能从一端传到另一端。

其最终功能和UDP一样，在端和端之间进行通信，但是和UDP的区别还是很大的。

###4、UPD和TCP的主要区别
下面，我们先从一张图中，了解TCP和UDP协议，在服务器数据报文上的处理区别：

![](https://xiuxian.junphp.com/public/kejian/v1-90.png)

UDP 与 TCP 的主要区别：

UDP 不一定提供可靠的数据传输。

事实上，该协议不能保证数据准确无误地到达目的地。

UDP 在许多方面也非常有效。

当某个程序的目标是尽快地传输尽可能多的信息时（其中任意给定数据的重要性相对较低），可使用UDP。

ICQ 短消息使用 UDP 协议发送消息。

许多程序将使用单独的TCP连接和单独的UDP连接。

重要的状态信息随可靠的TCP连接发送，而主数据流通过UDP发送。

TCP的目的是提供可靠的数据传输，并在相互进行通信的设备或服务之间保持一个虚拟连接。

TCP在数据包接收无序、丢失或在交付期间被破坏时，负责数据恢复。

它通过为其发送的每个数据包提供一个序号来完成此恢复。

记住，较低的网络层会将每个数据包视为一个独立的单元，

因此，数据包可以沿完全不同的路径发送，即使它们都是同一消息的组成部分。

这种路由与网络层处理分段和重新组装数据包的方式非常相似，只是级别更高而已。

为确保正确地接收数据，TCP要求在目标计算机成功收到数据时发回一个确认（即 ACK）。

如果在某个时限内未收到相应的 ACK，将重新传送数据包。

如果网络拥塞，这种重新传送将导致发送的数据包重复。

但是，接收计算机可使用数据包的序号来确定它是否为重复数据包，并在必要时丢弃它。

###5、UDP和TCP的选择
如果比较UDP包和TCP包的结构，很明显UDP包不具备TCP包复杂的可靠性与控制机制。

与TCP协议相同，UDP的源端口数和目的端口数也都支持一台主机上的多个应用。

一个16位的UDP包包含了一个字节长的头部和数据的长度，校验码域使其可以进行整体校验。

（许多应用只支持UDP，如：多媒体数据流，不产生任何额外的数据，即使知道有破坏的包也不进行重发。）

很明显，当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时，TCP协议是当然的选择。

当强调传输性能而不是传输的完整性时，如：音频和多媒体应用，UDP是最好的选择。

在数据传输时间很短，以至于此前的连接过程成为整个流量主体的情况下，UDP也是一个好的选择，如：DNS交换。

把SNMP建立在UDP上的部分原因是设计者认为当发生网络阻塞时，UDP较低的开销使其有更好的机会去传送管理数据。

TCP丰富的功能有时会导致不可预料的性能低下，但是我们相信在不远的将来，TCP可靠的点对点连接将会用于绝大多数的网络应用。

（现在大多的WEB长连接项目，都是使用的TCP协议）

### 6、TCP的三次握手
很多同学可能会疑惑：

在TCP建立连接的时候，为什么要经过三次握手方案，而不是两次？

因为两次握手的网络是不可靠的，因此多少次握手都不一定是可靠的连接。

三次是最少的握手次数，因为两次握手，响应端不知道发起端是否收到了响应报文，也就不能确信连接是否已经建立。

只有收到发送端的响应后，双方才能确认连接已经建立。

注意：UPD理论上就属于二次握手方案。

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手方案建立一个连接，主要步骤如下：
```
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
完成三次握手，客户端与服务器开始传送数据。
```

![](https://xiuxian.junphp.com/public/kejian/v1-91.png)

上述图解：

第一次握手：

客户端想与服务器进行连接了，所以状态变为主动打开，同时发送一个连接请求报文给服务器段SYN=1，并且会携带X个字节过去。

发送完请求连接报文后，客户端的状态就变为了SYN_SENT，可以说这个状态是等待发送确认(为了发送第三次握手时的确认包)。

第二次握手：

服务端接收到连接请求报文后，从接收请求状态变为被动打开状态，然后给客户端返回一个报文。

这个报文有两层意思，一是确认报文，而可以达到告诉客户端，我也打开连接了。

发完后，变为SYN_RCVD状态(也可以说是等待接受确认状态，接受客户端发过来的确认包)。

第三次握手：

客户端得到服务器端的确认和知道服务器端也已经准备好了连接后，还会发一个确认报文到服务器端，告诉服务器端，

我接到了你发送的报文，接下来就让我们两个进行连接了。

客户端发送完确认报文后，进入确立连接状态，而服务器接到了，也变为确立连接状态，到此三次握手成功。

疑问：

为什么需要第三次握手，有前面两次不就已经可以了吗？

假设没有第三次握手，客户端发送一个连接请求报文过去，

但是因为网络延迟，在等待了一个超时时间后，客户端就会在重新发一个请求连接报文过去，然后正常的进行，

服务器端发回一个确认连接报文，然后就开始通讯；

通讯结束后，那个第一次因为网络延迟的请求连接报文到了服务器端，服务器端不知道这个报文已经失效，也发回了一个确认连接报文，

客户端接收后，发现自己并没有发送连接请求(因为超时了，所以就认为自己没有发)，

所以对这个确认连接请求就什么也不做，但是此时客户端不这么认为，他认为i连接已经建立了，

就一直打开着等待客户端传数据过来，这就造成了极大的浪费。

如果有了第三次握手，那么客户端就可以通知服务器了。

所以第三次握手也很重要。

###7、TCP的四次挥手
可能很多同学会有疑惑，为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

这是因为服务端在接收请求的状态下，SOCKET当收到SYN报文的连接请求后，

它可以把ACK和SYN(ACK起应答作用，而SYN起同步作用)放在一个报文里来发送。

但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；

但未必你所有的数据都全部发送给对方了，所以你可能未必会马上会关闭SOCKET，

也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，

所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

![](https://xiuxian.junphp.com/public/kejian/v1-92.png)

第一次挥手：

从确立连接状态变为主动关闭状态，客户端主动发送释放连接请求给服务器端，FIN=1。

发送完之后就变为FIN_WAIT_1状态，这个状态可以说是等待确认状态。

第二次挥手：

服务器接收到客户端发来的释放连接请求后，状态变为CLOSE_WAIT，然后发送确认报文给客户端，告诉他我接收到了你的请求。

为什么变为CLOSE_WAIT，原因是是客户端发送的释放连接请求，可能自己这端还有数据没有发送完呢，所以这个时候整个TCP连接的状态就变为了半关闭状态。

服务器端还能发送数据，并且客户端也能接收数据，但是客户端不能在发送数据了，只能够发送确认报文。

客户端接到服务器的确认报文后，就进入了FIN_WAIT_2状态。也可以说这是等待服务器释放连接状态。

第三次挥手：

服务器端所有的数据度发送完了，认为可以关闭连接了，状态变为被动关闭，所以向客户端发送释放连接报文，

发完之后自己变为LAST_WAIT状态，也就是等待客户端确认状态。

第四次挥手：

客户端接到释放连接报文后，发送一个确认报文，然后自己变为TIME_WAIT，而不是立马关闭，

因为客户端发送的确认报文可能会丢失，丢失的话服务器就会重传一个FIN，也就是释放连接报文，这个时候客户端必须还没关闭。

当服务器接受到确认报文后，服务器就进入CLOSE状态，也就是关闭了。

但是由于上面说的这个原因，客户端必须等待一定的时间才能够进入CLOSE状态。

###8、TCP的半关闭状态
TCP连接是全双工的，所以它允许两个方向的数据被独立关闭。

换而言之，通信的一端可以发送结束报文给对方，告诉它本端已经完成了数据的发送，

但允许继续接收来自对方的数据，直到对方也发送结束报文以关闭连接。

TCP将这种连接状态称之为半连接状态，如下图：

![](https://xiuxian.junphp.com/public/kejian/v1-93.png)

注意：

上图中，服务器和客户端应用程序，判断对方是否已经关闭连接的方法是：

read系统调用返回0(表示收到结束报文)。

当然，Linux还提供了其他检测连接是否被对方关闭的方法。

###9、TCP的同时关闭连接
正常情况下，通信一方请求连接关闭，另一方响应连接关闭请求，并且被动关闭连接。

但是若出现同时关闭连接请求时，通信双方均从 确立连接 状态转换为 FIN_WAIT_1 状态。

任意一方收到对方发来的 FIN 报文段后，其状态均由 FIN_WAIT_1转变到 关闭连接 状态，并发送最后的 ACK 数据段。

当收到最后的 ACK 数据段后，状态转变化 TIME_WAIT，在等待 2MSL 时间后进入到 关闭连接 状态，最终释放整个 TCP 传输连接。

其过程如下：

![](https://xiuxian.junphp.com/public/kejian/v1-94.png)

举一个最常用TCP的例子，一般需要保证数据可靠时，都会使用TCP协议。

1、HTTP协议进行网站的访问时，使用的就是TCP。

###10、TIME_WAIT状态及其存在的必要性

![](https://xiuxian.junphp.com/public/kejian/v1-95.png)

从上图中可以看出，客户端连接在接收到服务器的结束报文段6之后，并没有进入关闭连接状态，而是转移到TIME_WAIT状态。

在这个状态，客户端连接需要等待一段长度为2MSL的司机，才能完全关闭。

MSL是TCP报文段在网络中最大的生存时间，标准是参照RFC1122文档中的建议值：2min。

TIME_WAIT状态存在的原因有2点：
```
1、可靠地终止TCP连接。
2、保证让迟来的TCP报文段有足够的司机被识别并丢弃。
```

第一个原因很好理解。

假设上图中用于确认服务器结束报文段6和TCP报文段7丢失，那么服务器将重发结束报文段。

因此客户端需要停留在某个状态以处理重复收到的结束报文段(既向服务器发送确认报文段)。

否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，

因为它期望的是一个像TCP报文段7这样的确认报文段。

在Linux操作系统中，一个TCP端口不能被同时打开多次(两次及以上)。

当一个TCP连接出于TIME_WAIT状态时，我们将无法立即使用该连接占用着的端口来建立一个新连接。

反过来思考，如果不存在TIME_WAIT状态，则应用程序能够立即建立一个和刚关闭的连接相似的连接(这里说的相似，是指它们具有相同的IP地址和端口号)。

这个新的、和原来相似的连接被称为原连接的化身。

新的化身可能接收到属于原来连接的、携带应用程序数据的TCP报文段(迟到的报文段)，这显然是不应该发生的。

这就是TIME_WAIT状态存在的第二个原因。

另外，因为TCP报文段的最大生成时间是MSL，所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上，

尚未被接收到的、迟到的TCP报文段都已经消息（被中转路由器丢弃）。

因此，从一个连接的新的化身可以在2MSL时间之后安全地建立，而绝对不会被接收到属于原连接的应用程序数据，

这就是TIME_WAIT状态要持续2MSL时间的原因。

已有0条评论

添加新评论☺

如果认为本文对您有所帮助请赞助本站

支付宝扫一扫赞助

已有0条评论

添加新评论☺