计算机网络参考模型

（1）osI参考模型

①物理层：完成相邻节点之间原始比特流的传输。

②数据链路层：将上层数据封装成固定格式的帧，在数据帧内封装发送端和接收端数据链路层地址，且在帧尾部添加校检信息，可在发现数据错误时重传数据帧。

③网络层：实现数据从源端到数据端的传输。

④传输层：实现网络中不同主机上用户进程之间的数据通信.

⑤会话层：允许不同机器上的用户之间建立会话关系

⑥表示层：用于完成某些特定功能：数据格式转化、加密等。

⑦应用层：为应用程序提供服务。

（2）TCP/IP协议簇

①物理层和数据链路层：支持所有标准的和专业的协议。

②网络层：TCP/IP定义了网络互联协议，IP由四个支撑协议组成：ARP（地址解析协议）、RARP（逆地址解析协议）、ICMP（网络控制报文协议）、IGMP（国际组管理协议）。

③传输层：TCP（传输控制协议）和UDP（用户数据报协议）。TCP协议传输稳定可靠，UDP协议传输效率更高。

④应用层：定义了许多协议，如HTTP（超文本传输）、FTP（文件传输协议）、SMTP（简单邮件传输协议）、DNS（域名系统）等。

（3）数据传输过程

①数据封装过程

（4）TCP和UDP协议

①TCP报文段：将若干个字节构成一个分组，称为报文段。TCP报文段封装在IP数据报中。

②TCP报文段的首部格式如图：

③TCP连接（三次握手和四次握手）

为了完成三次握手四次握手，这里需要知道序列号seq、确认应答序号ack（小写字母）、控制位：

序列号seq：因为在TCP是面向字节流的，他会将报文都分成一个个字节，给每个字节进行序号编写，比如一个报文有900个字节组成，那么就会编成1-900个序号，然后分几部分来进行传输，比如第一次传，序列号就是1，传了50个字节， 那么第二次传，序列号就为51，所以序列号就是传输的数据的第一个字节相对所有的字节的位置。

确认应答ack：如刚说的例子，第一次传了50个字节给对方，对方也会回应你，其中带有确认应答，就是告诉你下一次要传第51个字节来了，所以这个确认应答就是告诉对方下一次要传第多少个字节了。也就是说告诉序列号下一次从哪里开始

控制位目前有6个

URG:紧急，当URG为1时，表名紧急指针字段有效，标识该报文是一个紧急报文，传送到目标主机后，不用排队，应该让该报文尽量往下排，让其早点让应用程序给接受。

ACK:确认，当ACK为1时，确认序号才有效。当ACK为0时，确认序号没用。

PSH：推送，当为1时，当遇到此报文时，会减少数据向上交付，本来想应用进程交付数据是要等到一定的缓存大小才发送的，但是遇到它，就不用在等足够多的数据才向上交付，而是让应用进程早点拿到此报文，这个要和紧急分清楚，紧急是插队，但是提交缓存大小的数据不变，这个推送就要排队，但是遇到他的时候，会减少交付的缓存数据，提前交付。

RST:复位，报文遇到很严重的差错时，比如TCP连接出错等，会将RST置为1，然后释放连接，全部重新来过。

SYN：同步，在进行连接的时候，也就是三次握手时用得到，下面会具体讲到，配合ACK一起使用。

FIN：终止，在释放连接时，也就是四次握手时用的。

                                                                      三次握手

第一次握手：客户端想要连接，创建传输控制块TCB，状态变为主动打开。发送给服务器不包含数据内容的连接请求报文。该请求报文首部中同步位SYN=1，同时选择一个初始序列号seq=x（携带了x个字节）。然后客户端进入 SYN-SENT （同步已发送）状态，告诉服务器我想和你同步连接。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。

第二次握手：TCP服务器收到连接请求报文，如果同意连接则发送确认报文。为了保证下次客户端发送报文时seq序列号是正确的，需要发送确认号ack=x+1，同时确认号ack要生效必须发送ACK=1，再加上同步位SYN=1，序列号seq=y（携带Y个字节），然后服务器也进 入SYN-RCVD (同步已收到) 状态，完成同步连接。这个报文也是SYN报文，也不能携带数据，但是同样要消耗一个序号。 

第三次握手：客户端收到确认后还要再向服务器发送确认报文。确认报文已经不是请求报文SYN了，不再包含SYN同步位。发送的内容有序列号seq=x+1（和第二次握手的ACK对应），确认号ack=y+1，ACK=1。客户端发送确认报文以后进入ESTABLISHED（已建立）状态，服务器接收到确认报文以后也进入ESTABLISHED状态。此时TCP连接完成建立。

                                                                           四次握手

第一次握手：客户端从ESTABLISHED状态变为主动关闭状态，客户端发送请求释放连接报文给服务器，FIN=1，seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

第二次握手：服务器接收到客户端发来的请求释放报文以后，发送确认报文告诉客户端我收到了你的请求，内容差不多就是seq=v，ack=u+1，ACK=1，此时服务器进入CLOSE-WAIT（关闭等待）状态。

为什么是CLOSE-WAIT状态？可能自己服务器这端还有数据没有发送完，所以这个时候整个TCP的连接就变成了半关闭状态。服务器还能发送数据，客户端也能接收数据，但客户端不能再发送数据了，只能发送确认报文。

客户端接收到服务器传来的确认报文以后，进入 FIN-WAIT-1（终止等待2）状态，等待服务器发送连接释放的报文（在这之前，还需要接受服务器没有发送完的最后的数据）。 

第三次握手：服务器所有的数据都发送完了，认为可以关闭连接了，于是向客户端发送连接释放报文，内容FIN=1，seq=w，ack=u+1（客户端没发送消息，所以提醒客户端下一次还是从u+1开始发送序列），ACK=1。此时服务器进入了 LAST-ACK（最后确认）状态，等待客户端发送确认报文。

第四次握手：客户端接收到了服务器发送的连接释放报文，必须发出确认。确认报文seq=u+1，ack=w+1，ACK=1。此时客户端进入 TIME-WAIT （时间等待）状态，但是没有立马关闭。此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

因为这个确认报文可能丢失。服务器收不到确认报文心想这可能是我没传到或者丢失了啊，于是服务器再传一个FIN，然后客户端再重新发送一个确认报文。然后刷新2∗∗MSL时间。直到这个时间内收不到FIN连接释放报文，客户端撤销TCB进入CLOSE状态。

而服务器，在接收到确认报文的时候就立马变为CLOSE状态了。所以服务器结束TCP连接的时间略早于客户端。