计算机网络复习总结（中）

传输层

在前面的文章中我们总结了TCP/IP五层模型中的链路层和网络层，这两层主要负责的是主机和主机之间的通信，那么我们传输的数据到达主机之后呢？每台电脑上有那么多的应用程序，这些数据该分配给哪个进程？这就是这一章要提到的传输层的工作了。它主要负责的是端口与端口之间的通信。

TCP和UDP

在传输层中最重量级的两个协议，就是UDP和TCP
1.UDP（User Data Protocol）用户数据报协议

• 使用UDP协议的主机可以在任意时刻发送数据，远程主机接收数据后也无需返回响应
• 虽然UDP协议提供无连接，不可靠的服务，但是在一些即时通信的场景经常使用（QQ,微信）

2.TCP（Transmission Control Protocol）传输控制协议

• TCP提供面向连接的服务，在发送数据前要建立连接，发送完成后要断开连接。
• TCP提供可靠的传输服务，所以TCP不支持广播和多播（仅一对一），这使得TCP报文的首部增大很多，并且还会占用处理机资源
• TCP一般用于传输文件，远程登录，发送接收邮件等场景

TCP报文段首部格式

TCP 报文段的具体格式大家可以不必都记住，但是其中的几个控制位与我们接下来要讲的三次握手和四次挥手息息相关，大家一定要牢记。

1. 源端口和目的端口：各占两个字节，是源主机和目的主机对应进程的端口号
2. 序号/序列号（Sequence Number，SN）：在TCP传输的数据中每一个字节都是按顺序编号的，序号就是此次发送数据的第一个字节的序号。初始学号称为Init Sequence Number
3. 确认号ack：期望收到对方发送过来的下一个报文段的第一个字节的序号，如果确认好为N，就表面序号N-1及之前的数据都成功收到了。
4. 控制位（保留右边的六个字段）：

1.URG-紧急位：当URG=1时，表明当前报文段中有紧急数据，是高优先级的数据，不必在缓存中排队，应该尽快发送。URG和紧急指针配合使用，紧急指针用来指出当前报文段紧急数据的字节数。（比如说有个病毒程序我想马上中断它，如果没有URG，这个指令还得在队列中排队等待处理，黄花菜都凉了）
2.ACK-确认：这个和确认号ack不是一个东西，ACK=1的时候ack确认号才是有效的，ACK=0的话ack是无效的，规定TCP连接建立之后ACK都要置一
3.PSH-推送：在两个进程交互通信时，有时某个进程想另一个进程立刻响应本次发送的指令，那么此时就可使用PUSH操作，发送方TCP把PUSH置1，然后把报文段发送出去，接收方收到后查看报文段的PUSH=1，就尽快交付接收应用进程，而不是等待缓存填满再向上交付
4.RST-复位：当TCP连接出现了严重错误的时候（主机崩溃或其他），需要释放连接再重新建立
5.SYN-同步：SYN=1时表示这是一个连接请求或者连接接受响应报文
当 SYN = 1 而 ACK = 0 时，表明这是一个连接请求报文段。对方若同意建立连接，则应在响应的报文段中使 SYN = 1 且 ACK = 1。
6.FIN-终止：用来释放一个连接，当FIN=1时表示我这一端的数据已经发送完成了，请求释放连接。

上述解析了TCP首部报文里的各个字段和6个控制位的含义，就是因为TCP提供可靠连接就是靠的上述的这些东西，接下来我们来解析一下TCP三次握手建立连接和四次挥手释放连接的过程

TCP三次握手建立连接

进行三次握手主要是为了确认发收双方的发送和接收数据能力是否正常，必须是三次吗？两次行不行，四次行不行？

我们先来看一下三次握手的过程：

回顾一下上述字符的含义：

• SYN：连接请求/响应报文
• seq：序列号，表示本报文段第一个字节的序列号
• ACK：确认，为1时表示连接已建立，ack有效
• ack：确认号，ack=x+1,表示前x个字节数据都正常接收，并且表示下一个想收到的数据开头序号为x+1

刚开始的时候客户端处于CLOSED状态，服务端处于LISTEN状态

CLOSED ：没有任何连接状态
LISTEN ：侦听来自远方 TCP 端口的连接请求

第一次握手
客户端发送一个SYN=1的连接请求报文，然后该报文还包含一个初始序列号
seq=x，表示这个报文第一个字节的序号，此时客户端处于SYN_Sent状态
（SYN_Sent:发送连接请求报文后等待匹配连接的状态）
第二次握手
服务端收到客户端的SYN报文之后，也发送一个SYN=1的响应报文，并且也把自己的初始序列号seq=y，以及确认号ack=x+1加进报文中，表示成功收到了客户端的连接请求报文，记得还要把ACK置1，此时服务端处于
SYN_RCVD状态（收到连接请求报文后，等待对方的连接响应报文）
第三次握手
客户端收到服务端的SYN报文后，此时已经确定服务端的发送和接收能力正常，这时客户端会发送一个ACK报文给服务端，ACK报文里包含ack=y+1的确认号，seq=x+1的序列号，表示将x+1开头的报文段发送过去，并且也将ACK置1，此时客户端从SYN_SENT->Established状态，表示连接建立

在服务端收到ACK报文后，也从SYN_RCVD->Established状态。
至此，TCP连接建立完成。

那么再回到上面的问题，为什么一定要三次握手，我们来分析一下：
第一次握手，客户端发送SYN报文，此时服务端收到后知道客户端的发送能力正常，自己的接收能力正常；客户端啥也不知道。
第二次握手，客户端收到服务端的SYN报文，知道自己的发送和接收能力正常，服务端的发送和接收能力也正常，但是服务端还是只知道客户端的发送能力正常，自己的接收能力正常
第三次握手，服务端再收到客户端的ACK报文之后，知道了自己的发送和接收能力正常，对方的发送和接收能力也正常。
所以两次握手不能保证是可靠、安全的连接，四次握手就有些多余，浪费网络流量。

三次握手过程中可以发送数据吗？
第一、二次不行，第三次握手可以，因为第一、第二次握手都处于连接建立的状态，如果在这时候有攻击者一直向服务端发送SYN报文并且携带大量数据（攻击者是不需要理会服务端的接收能力的），服务端会耗费大量的时间和内存去处理这些SYN恶意报文，得不偿失。

简单的记忆就是当SYN=1的时候，不可以携带数据。

而第三次的时候，此时客户端已经处于Established状态，知道服务端的发送接收正常，自然可以携带数据。

半连接队列
当服务端处于SYN_RCVD状态时，此时双方还没有完全建立连接，服务器会把这种状态下的SYN报文放在一个队列里，这个队列就是半连接队列，还有一个全连接队列，就是当第三次握手之后，所有报文都会放在全连接队列里，如果队列满了还可能会丢包。

SYN泛洪攻击
攻击者伪造大量不存在的IP地址，然后给服务器发送大量SYN报文，那么服务器就得不断的响应，并等待客户端的ACK报文，但是由于IP地址根本不存在，所以半连接队列会被这些虚