--- sidebar: heading ---  ## 网络分层结构 计算机网络体系大致分为三种，OSI七层模型、TCP/IP四层模型和五层模型。一般面试的时候考察比较多的是五层模型。  **五层模型**：应用层、传输层、网络层、数据链路层、物理层。 - **应用层**：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统DNS、HTTP协议、SMTP协议等。 - **传输层**：负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。 - **网络层**：选择合适的路由和交换结点，确保数据及时传送。主要包括IP协议。 - **数据链路层**：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。 - **物理层**：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和物理设备的差异。 **ISO七层模型**是国际标准化组织（International Organization for Standardization）制定的一个用于计算机或通信系统间互联的标准体系。 - 应用层：网络服务与最终用户的一个接口，常见的协议有：**HTTP FTP SMTP SNMP DNS**. - 表示层：数据的表示、安全、压缩。，确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。 - 会话层：建立、管理、终止会话,对应主机进程，指本地主机与远程主机正在进行的会话. - 传输层：定义传输数据的协议端口号，以及流控和差错校验,协议有**TCP UDP**. - 网络层：进行逻辑地址寻址，实现不同网络之间的路径选择,协议有**ICMP IGMP IP等**. - 数据链路层：在物理层提供比特流服务的基础上，建立相邻结点之间的数据链路。 - 物理层：建立、维护、断开物理连接。 **TCP/IP 四层模型** - 应用层：对应于OSI参考模型的（应用层、表示层、会话层）。 - 传输层: 对应OSI的传输层，为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性。 - 网际层：对应于OSI参考模型的网络层，主要解决主机到主机的通信问题。 - 网络接口层：与OSI参考模型的数据链路层、物理层对应。 ## 三次握手 假设发送端为客户端，接收端为服务端。开始时客户端和服务端的状态都是`CLOSED`。  1. 第一次握手：客户端向服务端发起建立连接请求，客户端会随机生成一个起始序列号x，客户端向服务端发送的字段中包含标志位`SYN=1`，序列号`seq=x`。第一次握手前客户端的状态为`CLOSE`，第一次握手后客户端的状态为`SYN-SENT`。此时服务端的状态为`LISTEN`。 2. 第二次握手：服务端在收到客户端发来的报文后，会随机生成一个服务端的起始序列号y，然后给客户端回复一段报文，其中包括标志位`SYN=1`，`ACK=1`，序列号`seq=y`，确认号`ack=x+1`。第二次握手前服务端的状态为`LISTEN`，第二次握手后服务端的状态为`SYN-RCVD`，此时客户端的状态为`SYN-SENT`。（其中`SYN=1`表示要和客户端建立一个连接，`ACK=1`表示确认序号有效） 3. 第三次握手：客户端收到服务端发来的报文后，会再向服务端发送报文，其中包含标志位`ACK=1`，序列号`seq=x+1`，确认号`ack=y+1`。第三次握手前客户端的状态为`SYN-SENT`，第三次握手后客户端和服务端的状态都为`ESTABLISHED`。**此时连接建立完成。** ## 两次握手可以吗？ 之所以需要第三次握手，主要为了**防止已失效的连接请求报文段**突然又传输到了服务端，导致产生问题。 - 比如客户端A发出连接请求，可能因为网络阻塞原因，A没有收到确认报文，于是A再重传一次连接请求。 - 然后连接成功，等待数据传输完毕后，就释放了连接。 - 然后A发出的第一个连接请求等到连接释放以后的某个时间才到达服务端B，此时B误认为A又发出一次新的连接请求，于是就向A发出确认报文段。 - 如果不采用三次握手，只要B发出确认，就建立新的连接了，**此时A不会响应B的确认且不发送数据，则B一直等待A发送数据，浪费资源。** ## 四次挥手  1. A的应用进程先向其TCP发出连接释放报文段（`FIN=1，seq=u`），并停止再发送数据，主动关闭TCP连接，进入`FIN-WAIT-1`（终止等待1）状态，等待B的确认。 2. B收到连接释放报文段后即发出确认报文段（`ACK=1，ack=u+1，seq=v`），B进入`CLOSE-WAIT`（关闭等待）状态，此时的TCP处于半关闭状态，A到B的连接释放。 3. A收到B的确认后，进入`FIN-WAIT-2`（终止等待2）状态，等待B发出的连接释放报文段。 4. B发送完数据，就会发出连接释放报文段（`FIN=1，ACK=1，seq=w，ack=u+1`），B进入`LAST-ACK`（最后确认）状态，等待A的确认。 5. A收到B的连接释放报文段后，对此发出确认报文段（`ACK=1，seq=u+1，ack=w+1`），A进入`TIME-WAIT`（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间`2MSL`（最大报文段生存时间）后，A才进入`CLOSED`状态。B收到A发出的确认报文段后关闭连接，若没收到A发出的确认报文段，B就会重传连接释放报文段。 ## 第四次挥手为什么要等待2MSL？ - **保证A发送的最后一个ACK报文段能够到达B**。这个`ACK`报文段有可能丢失，B收不到这个确认报文，就会超时重传连接释放报文段，然后A可以在`2MSL`时间内收到这个重传的连接释放报文段，接着A重传一次确认，重新启动2MSL计时器，最后A和B都进入到`CLOSED`状态，若A在`TIME-WAIT`状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到B重传的连接释放报文段，所以不会再发送一次确认报文段，B就无法正常进入到`CLOSED`状态。 - **防止已失效的连接请求报文段出现在本连接中**。A在发送完最后一个`ACK`报文段后，再经过2MSL，就可以使这个连接所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现旧的连接请求报文段。 ## 为什么是四次挥手？ 因为当Server端收到Client端的`SYN`连接请求报文后，可以直接发送`SYN+ACK`报文。**但是在关闭连接时，当Server端收到Client端发出的连接释放报文时，很可能并不会立即关闭SOCKET**，所以Server端先回复一个`ACK`报文，告诉Client端我收到你的连接释放报文了。只有等到Server端所有的报文都发送完了，这时Server端才能发送连接释放报文，之后两边才会真正的断开连接。故需要四次挥手。 ## TCP有哪些特点？ - TCP是**面向连接**的运输层协议。 - **点对点**，每一条TCP连接只能有两个端点。 - TCP提供**可靠交付**的服务。 - TCP提供**全双工通信**。 - **面向字节流**。 ## 说说TCP报文首部有哪些字段，其作用又分别是什么？  - **16位端口号**：源端口号，主机该报文段是来自哪里；目标端口号，要传给哪个上层协议或应用程序 - **32位序号**：一次TCP通信（从TCP连接建立到断开）过程中某一个传输方向上的字节流的每个字节的编号。 - **32位确认号**：用作对另一方发送的tcp报文段的响应。其值是收到的TCP报文段的序号值加1。 - **4位头部长度**：表示tcp头部有多少个32bit字（4字节）。因为4位最大能标识15，所以TCP头部最长是60字节。 - **6位标志位**：URG(紧急指针是否有效)，ACk（表示确认号是否有效），PSH（缓冲区尚未填满），RST（表示要求对方重新建立连接），SYN（建立连接消息标志接），FIN（表示告知对方本端要关闭连接了） - **16位窗口大小**：是TCP流量控制的一个手段。这里说的窗口，指的是接收通告窗口。它告诉对方本端的TCP接收缓冲区还能容纳多少字节的数据，这样对方就可以控制发送数据的速度。 - **16位校验和**：由发送端填充，接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。注意，这个校验不仅包括TCP头部，也包括数据部分。这也是TCP可靠传输的一个重要保障。 - **16位紧急指针**：一个正的偏移量。它和序号字段的值相加表示最后一个紧急数据的下一字节的序号。因此，确切地说，这个字段是紧急指针相对当前序号的偏移，不妨称之为紧急偏移。TCP的紧急指针是发送端向接收端发送紧急数据的方法。 ## TCP和UDP的区别？ 1. TCP**面向连接**；UDP是无连接的，即发送数据之前不需要建立连接。 2. TCP提供**可靠的服务**；UDP不保证可靠交付。 3. TCP**面向字节流**，把数据看成一连串无结构的字节流；UDP是面向报文的。 4. TCP有**拥塞控制**；UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如实时视频会议等）。 5. 每一条TCP连接只能是**点到点**的；UDP支持一对一、一对多、多对一和多对多的通信方式。 6. TCP首部开销20字节；UDP的首部开销小，只有8个字节。 ## TCP 和 UDP 分别对应的常见应用层协议有哪些？ **基于TCP的应用层协议有：HTTP、FTP、SMTP、TELNET、SSH** - **HTTP**：HyperText Transfer Protocol（超文本传输协议），默认端口80 - **FTP**: File Transfer Protocol (文件传输协议), 默认端口(20用于传输数据，21用于传输控制信息) - **SMTP**: Simple Mail Transfer Protocol (简单邮件传输协议) ,默认端口25 - **TELNET**: Teletype over the Network (网络电传), 默认端口23 - **SSH**：Secure Shell（安全外壳协议），默认端口 22 **基于UDP的应用层协议：DNS、TFTP、SNMP** - **DNS** : Domain Name Service (域名服务),默认端口 53 - **TFTP**: Trivial File Transfer Protocol (简单文件传输协议)，默认端口69 - **SNMP**：Simple Network Management Protocol（简单网络管理协议），通过UDP端口161接收，只有Trap信息采用UDP端口162。 ## TCP的粘包和拆包 TCP是面向流，没有界限的一串数据。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一**个完整的包可能会被TCP拆分成多个包进行发送**，**也有可能把多个小的包封装成一个大的数据包发送**，这就是所谓的TCP粘包和拆包问题。 **为什么会产生粘包和拆包呢?** - 要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包； - 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包； - 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包； - 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。即TCP报文长度-TCP头部长度>MSS。 **解决方案：** - 发送端将每个数据包封装为固定长度 - 在数据尾部增加特殊字符进行分割 - 将数据分为两部分，一部分是头部，一部分是内容体；其中头部结构大小固定，且有一个字段声明内容体的大小。 ## 说说TCP是如何确保可靠性的呢？ - 首先，TCP的连接是基于**三次握手**，而断开则是基于**四次挥手**。确保连接和断开的可靠性。 - 其次，TCP的可靠性，还体现在**有状态**;TCP会记录哪些数据发送了，哪些数据被接收了，哪些没有被接受，并且保证数据包按序到达，保证数据传输不出差错。 - 再次，TCP的可靠性，还体现在**可控制**。它有数据包校验、ACK应答、**超时重传(发送方)**、失序数据重传（接收方）、丢弃重复数据、流量控制（滑动窗口）和拥塞控制等机制。 ## 说下TCP的滑动窗口机制 TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 TCP会话的双方都各自维护一个发送窗口和一个接收窗口。接收窗口大小取决于应用、系统、硬件的限制。发送窗口则取决于对端通告的接收窗口。接收方发送的确认报文中的window字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将接收方的确认报文window字段设置为 0，则发送方不能发送数据。  TCP头包含window字段，16bit位，它代表的是窗口的字节容量，最大为65535。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。接收窗口的大小是约等于发送窗口的大小。 ## 详细讲一下拥塞控制？ 防止过多的数据注入到网络中。 几种拥塞控制方法：慢开始( slow-start )、拥塞避免( congestion avoidance )、快重传( fast retransmit )和快恢复( fast recovery )。  **慢开始** 把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。每经过一个传输轮次，拥塞窗口 cwnd 就加倍。 为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量。 当 cwnd < ssthresh 时，使用慢开始算法。 当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。 当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞控制避免算法。 **拥塞避免** 让拥塞窗口cwnd缓慢地增大，每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长。 无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送 方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生 拥塞的路由器有足够时间把队列中积压的分组处理完毕。 **快重传** 有时个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开始，把拥塞窗口cwnd又设置为1，因而降低了传输效率。 快重传算法可以避免这个问题。快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认，使发送方及早知道有报文段没有到达对方。 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待重传计时器到期。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。 **快恢复** 当发送方连续收到三个重复确认，就会把慢开始门限ssthresh减半，接着把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。 在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用。 采用这样的拥塞控制方法使得TCP的性能有明显的改进。 ## HTTP协议的特点？ 1. HTTP允许传输**任意类型**的数据。传输的类型由Content-Type加以标记。 2. **无状态**。对于客户端每次发送的请求，服务器都认为是一个新的请求，上一次会话和下一次会话之间没有联系。 3. 支持**客户端/服务器模式**。 ## HTTP报文格式 HTTP请求由**请求行、请求头部、空行和请求体**四个部分组成。 - **请求行**：包括请求方法，访问的资源URL，使用的HTTP版本。`GET`和`POST`是最常见的HTTP方法，除此以外还包括`DELETE、HEAD、OPTIONS、PUT、TRACE`。 - **请求头**：格式为“属性名:属性值”，服务端根据请求头获取客户端的信息，主要有`cookie、host、connection、accept-language、accept-encoding、user-agent`。 - **请求体**：用户的请求数据如用户名，密码等。 **请求报文示例**： ```java POST /xxx HTTP/1.1 请求行 Accept:image/gif.image/jpeg, 请求头部 Accept-Language:zh-cn Connection:Keep-Alive Host:localhost User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0) Accept-Encoding:gzip,deflate username=dabin 请求体 ``` HTTP响应也由四个部分组成，分别是：**状态行、响应头、空行和响应体**。 - **状态行**：协议版本，状态码及状态描述。 - **响应头**：响应头字段主要有`connection、content-type、content-encoding、content-length、set-cookie、Last-Modified，、Cache-Control、Expires`。 - **响应体**：服务器返回给客户端的内容。 **响应报文示例**： ```html HTTP/1.1 200 OK Server:Apache Tomcat/5.0.12 Date:Mon,6Oct2003 13:23:42 GMT Content-Length:112