(ROOT)网络模型详解

https://www.cnblogs.com/inception6-lxc/p/9152691.html

https://www.cnblogs.com/maybe2030/p/4781555.html#_label3

网络模型

 物理层

 激活、维持、关闭通信端点之间的机械特性、电气特性、功能特性以及过程特性。该层为上层协议提供了一个传输数据的可靠的物理媒体。简单的说，物理层确保原始的数据可在各种物理媒体上传输。物理层记住两个重要的设备名称，中继器（Repeater，也叫放大器）和集线器。

数据链路层

数据链路层在物理层提供的服务的基础上向网络层提供服务，其最基本的服务是将源自网络层来的数据可靠地传输到相邻节点的目标机网络层。为达到这一目的，数据链路必须具备一系列相应的功能，主要有：如何将数据组合成数据块，在数据链路层中称这种数据块为帧（frame），帧是数据链路层的传送单位；如何控制帧在物理信道上的传输，包括如何处理传输差错，如何调节发送速率以使与接收方相匹配；以及在两个网络实体之间提供数据链路通路的建立、维持和释放的管理。数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。

网络层

　网络层的目的是实现两个主机系统之间的数据透明传送，具体功能包括寻址和路由选择、连接的建立、保持和终止等。它提供的服务使传输层不需要了解网络中的数据传输和交换技术。如果您想用尽量少的词来记住网络层，那就是“路径选择、路由及逻辑寻址”。

　　网络层中涉及众多的协议，其中包括最重要的协议，也是TCP/IP的核心协议——IP协议。IP协议非常简单，仅仅提供不可靠、无连接的传送服务。IP协议的主要功能有：无连接数据报传输、数据报路由选择和差错控制。与IP协议配套使用实现其功能的还有地址解析协议ARP、逆地址解析协议RARP、因特网报文协议ICMP、因特网组管理协议IGMP。具体的协议我们会在接下来的部分进行总结，有关网络层的重点为：

　　　　1> 网络层负责对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能；

　　　　2> 基本数据单位为IP数据报；

　　　　3> 包含的主要协议：

　　　　IP协议（Internet Protocol，因特网互联协议）;

　　　　ICMP协议（Internet Control Message Protocol，因特网控制报文协议）;

　　　　ARP协议（Address Resolution Protocol，地址解析协议）可看成是跨网络层和链路层的协议;

　　　　RARP协议（Reverse Address Resolution Protocol，逆地址解析协议）。

　　　　4> 重要的设备：路由器。

传输层

第一个端到端，即主机到主机的层次。传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输。此外，传输层还要处理端到端的差错控制和流量控制问题。

　　传输层的任务是根据通信子网的特性，最佳的利用网络资源，为两个端系统的会话层之间，提供建立、维护和取消传输连接的功能，负责端到端的可靠数据传输。在这一层，信息传送的协议数据单元称为段或报文。作用：为应用进程之间提供端到端的逻辑通信。

　　网络层只是根据网络地址将源结点发出的数据包传送到目的结点，而传输层则负责将数据可靠地传送到相应的端口。

　　有关传输层的重点：

　　1> 传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输以及端到端的差错控制和流量控制问题；

　　2> 包含的主要协议：TCP协议（Transmission Control Protocol，传输控制协议）、UDP协议（User Datagram Protocol，用户数据报协议）；

　　3> 重要设备：网关。

会话层

　　会话层管理主机之间的会话进程，即负责建立、管理、终止进程之间的会话。会话层还利用在数据中插入校验点来实现数据的同步。

表示层

　　表示层对上层数据或信息进行变换以保证一个主机应用层信息可以被另一个主机的应用程序理解。表示层的数据转换包括数据的加密、压缩、格式转换等。

应用层

　　是最靠近用户的OSI层，为用户的应用程序提供网络服务的接口。将用户的操作通过应用程序转换成为服务，并匹配一个相应的服务协议发送给传输层。

       注：我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议。

应用层协议和传输层协议的关系

下面是一些常见的应用层协议和传输层协议之间的关系。

HTTP默认使用TCP的80端口标识

FTP默认使用TCP的21端口标识

SMTP默认使用TCP的25端口标识

POP3默认使用TCP的110端口

HTTPS默认使用TCP的443端口

DNS使用UDP的53端口

远程桌面协议（RDP）默认使用TCP的3389端口

Telnet使用TCP的23端口

Windows访问共享资源使用TCP的445端口

各层协议

每一层的协议如下：

7	应用层	例如HTTP、SMTP、SNMP、FTP、Telnet、SIP、SSH、NFS、RTSP、XMPP、Whois、ENRP
6	表示层	例如XDR、ASN.1、SMB、AFP、NCP
5	会话层	例如ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets
4	传输层	例如TCP、UDP、RTP、SCTP、SPX、ATP、IL
3	网络层	例如IP、ICMP、IGMP、IPX、BGP、OSPF、RIP、IGRP、EIGRP、ARP、RARP、 X.25
2	数据链路层	例如以太网、令牌环、HDLC、帧中继、ISDN、ATM、IEEE 802.11、FDDI、PPP
1	物理层	例如线路、无线电、光纤、信鸽

三次握手四次挥手

（sub）三次握手四次挥手-CSDN博客

TCP规定：

TCP规定，在连接建立后所有报文的传输都必须把ACK置1；

TCP规定SYN=1报文段不能携带数据，但是要消耗一个序号；

当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；

TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号；

 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

报文详解

源端口和目的端口，各占2个字节，分别写入源端口和目的端口；
序号，占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号。例如，一段报文的序号字段值是 301 ，而携带的数据共有100字段，显然下一个报文段（如果还有的话）的数据序号应该从401开始；
确认号，占4个字节，是期望收到对方下一个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701；
数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远；
保留，占6位，保留今后使用，但目前应都位0；
紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；
复位RST，当RST=1，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立连接；
同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放；
窗口，占2字节，指的是通知接收方，发送本报文你需要有多大的空间来接受；
检验和，占2字节，校验首部和数据这两部分；
紧急指针，占2字节，指出本报文段中的紧急数据的字节数；
选项，长度可变，定义一些其他的可选的参数。
————————————————
版权声明：本文为CSDN博主「小书go」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qzcsu/article/details/72861891

三次握手

 转载自：两张动图-彻底明白TCP的三次握手与四次挥手_tcp三次握手和4次挥手的过程_小书go的博客-CSDN博客

 步骤：

0.服务器ready，通常通过调用 socket,bind和listen这三个函数来完成，称之为 被动打开。

1.（第一次握手）connect发起，客户端主动向服务器发出连接请求的TCP报文段，其TCP首部中的同步比特SYN置为1，ACK=0，并TCP首部中序号seq设置为x（TCP规定SYN=1报文段不能携带数据，但是要消耗一个序号），表明要转送数据时初始序列号是x。通常SYN分节不携带数据，其所在IP数据报只含有一个IP首部，一个TCP首部。
2.（第二次握手）服务器收到数据报后，从TCP数据报首部的同步比特SYN位为1就知道这是一个建立连接的请求。服务器如果同意，会发回确认。在确认报文段中把同步比特位SYN设置为1，确认比特位ACK设置为1，由于TCP请求报文段中的序号是x，所以服务器在发送确认报文段中的确认号ack是x+1，同时把确认报文段中的序号seq设置为y，表明服务器发送数据的初始序列号为y。该报文段也不能携带数据（因为SYN=1，所以不携带任何数据）。
3.（第三次握手）客户端收到服务器端的报文段后，要对服务器端中的SYN进行确认。在确认报文段中把确认比特位ACK设置为1，然后把确认号ack设置为y+1，自身的序号seq设置x+1。
注：客户的初始序列号为x,服务器的初始序列号为y，那么确认报文段中的确认号ack就是所期待的对方要发送的下一个序列号。

握手异常处理：

出错返回可能有的几种情况。
（1）客户端发送的建立连接的SYN报文丢失或者服务器回复的ACK报文丢失。客户端因为没有收到服务器的回复，会等待6s再发一次，若无响应则等待24s再发一次，总共等75s还未收到响应就返回本错误。
（2）服务器回复的TCP报文中复位标志RST置位1。表示服务器主机没有在指定的端口上监听或接受该连接或服务器程序根本没有运行。
（3）客户端发送的SYN报文不可达。还记IP数据报中有一个生存时间(TTL)的标志吗？它每经过一个路由器都会减1，当它减到0时还没到达目的地，会发送一个ICMP错误。然后客户端会和第一种情况一样每隔一段时间重发一次。

为什么要3次握手

可以把TCP连接时的三次握手换成两次握手吗？（假设客户端主动，服务器端被动）
假如客户端发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达服务器。也就是说这是一个早已失效的报文段。但服务器端收到此失效的连接请求报文段后，就误认为是客户端再次发出的一个新的连接请求。于是就向客户端发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要服务器端发出确认，新的连接就建立了。由于现在客户端并没有发出建立连接的请求，因此不会理会服务器端的确认。经过三次握手，客户端和服务器都有应有答可以确保TCP正确连接。

如果第三次握手没发到服务端？

TCP/IP(二十一)TCP 实战抓包分析(五)TCP 第三次握手 ACK 丢包_tcp ack包丢失-CSDN博客

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

四次挥手

 转载自：两张动图-彻底明白TCP的三次握手与四次挥手_tcp三次握手和4次挥手的过程_小书go的博客-CSDN博客

步骤

0.数据传输完毕后，通信双方都可以释放连接。对于首先调用close的一端我们称该端为 主动关闭，另外一端执行 被动关闭。
1.（第一次挥手）假设客户端执行 主动关闭，那么它会向服务器端发出释放连接的报文段，这个TCP报文段中终止比特FIN置为1，序号seq设置为u（假设上一个发的数据序号是u-1）。并停止发送数据。主动关闭TCP连接。等待服务器的确认，这里需要注意，因为TCP是全双工的，所以TCP连接上有两条数据通路，发送FIN的一端就不能发送数据，也就是关闭了其中一条数据通路，对方还是可以继续发送数据。
2.（第二次挥手）服务器端收到客户端的释放连接的报文段后会执行被动关闭，它要对客户端的数据报进行确认，服务器端会发送一个确认的数据报，确认比特ACK设置为1，确认号为u+1，自身的序号seq为v(假设上一个发的数据序号是v-1)。这个时候TCP处于半关闭状态，服务器依然可以向客户端发送数据（数据的序号为v+1 ~ w-1），客户端任要接受。
3.（第三次挥手）服务器端已经没有要发送给客户端的数据，那么服务器端也会调用close关闭套接字，这样服务器端也会发送一个FIN的TCP报文段，序号是w（假设上一个发的数据序号是w-1）。这个时候服务器端不会再向客户端发送数据了。
4.（第四次挥手）客户端接受到这个最终的FIN的释放连接报文段后必须对报文段进行确认。在确认的报文段中，ACK=1,确认序号ack=w+1，自己的序号seq=u+1(他的上一个序号的数据报就是申请释放连接的数据报，序号是seq=u)。

为什么TCP握手是三次，挥手却是四次？（假设客户端主动，服务器端被动）

在TCP三次握手中，服务器端的SYN和ACK是放在一个TCP报文段中向客户端发送的，而在断开连接的过程中，服务器端向客户单端发送的ACK和FIN是是分别在两个不同的TCP报文段中。这是因为在服务器端接收到客户端的FIN后，服务器端可能还有数据要传输，所以先发送ACK，服务器端把数据发完之后就可以发送FIN断开连接了。

TIME_WAIT

TIME_WAIT状态 （假设客户端主动，服务器端被动）
从状态图中我们可以发现，执行主动关闭的那端（最终重传ACK的那端）会经历这个状态。这个状态停留是的时间是2MSL（MSL:最长报文段生存时间，1~4分钟）。
TIME_WAIT状态的作用：
1、可靠地实现TCP的连接终止。
在终止TCP连接时有4个报文需要交换，其中最后一个ACK报文是由客户端发往服务器。假设这个ACK报文在网络中被丢弃了，那么服务器端收不到这个确认ACK，服务器端会向客户端再次发送FIN。这就是为什么TIME_WAIT状态持续2倍的最长报文段生存时间：1MSL时间留给最后的ACK确认报文段到达服务器端，1MSL时间留给服务器端再次发送的FIN（这一段摘抄自《unix系统编程手册》P1046，我不明白，超过2MSL连接就超时关闭了，再次发送FIN后，即客户端刚收到，2MSL时间也就到了，连接就关闭了，再次发送FIN的意义何在？,希望有知道的同学告诉我）。

2、确保老的重复的报文段在网络中过期失效，这样建立新的连接时将不再接受它们。
TCP协议采用的是出错重传，也就是会生成重复的报文，并且根据路由器的选择，这些重复的报文可能在连接终止后才到达，如果客户端/服务器端收到这个老的报文会把它误认为一个同一连接的新的报文，然后对这个报文进行处理，这样就会出现错误。从状态转换图我们可以看到从TIME_WAIT到连接终止，中间有2MSL，这个时间足以让老的重复的报文段过期失效。

TIME_WAIT会出现在服务器吗？
会的，TIME_WATI存在首先执行主动关闭的那端，比如爬虫服务器他本身其实就是客户端，完成爬取任务后，执行关闭，那么所有的TCP连接都会处于TIME_WAIT状态。

TIME_WAIT的危害：Linux分配给一个用户的文件句柄是有限的，如果系统中存在大量的TIME_WAIT状态，一旦达到句柄数上限，新的请求就无法被处理了，而且大量TIME_WAIT连接占用资源影响性能。

如何关闭TIME_WAIT状态或者让TIME_WAIT状态过早终止？
对/etc/sysctl.conf文件内容进行修改：

#表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭  
net.ipv4.tcp_tw_reuse = 1  
#表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭  
net.ipv4.tcp_tw_recycle = 1  

虽然我们可以这么做，但是我们应该避免这样做，因为这样会阻碍TIME_WAIT状态提供的可靠性保证。

CLOSE_WAIT

CLOSE_WAIT状态（假设客户端主动，服务器端被动）
被动关闭的那端会经历这个状态。如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在客户端关闭连接之后服务器程序自己没有进一步发出FIN报文，一般原因都是TCP连接没有调用关闭方法，或者对方连接关闭之后程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行，一定程度上，可以使用TCP的keepalive功能，让操作系统替我们自动清理掉CLOSE_WAIT连接。

#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒  
net.ipv4.tcp_keepalive_time=1200