秋招总结(二)-计算机网络归纳

绝地灬酷狼 2024-04-17 06:08 69阅读 0赞

### 1.网络编程一般步骤： ###

*  TCP：

1.  服务端： socket->bind->listen->accept->recv/send->close
2.  客户端：socket->connect->send/recv->close

*  UDP:

1.  服务端：socket->bind->recvfrom/sendto->close
2.  客户端：socket->sendto/recvfrom->close

### 2.TCP和UDP的区别： ###

*  TCP面向连接（三次握手），通信前需要先建立连接；UDP面向无连接，通信前不需要连接。
 *  TCP通过序号、重传、流量控制、拥塞控制实现可靠传输；UDP不保障可靠传输，尽最大努力交付。
 *  TCP面向字节流传输，因此可以被分割并在接收端重组；UDP面向数据报传输。

### 3.三次握手 ###

*  第一次：主动发起连接方发送含SYN位，并初始化一个 同步序列号= S 的包到接收方 （发送方->SYN\_SEND）
 *  第二次：接收方收到后，发送一个含ACK位和SYN位，确认号 = S+1， 并且初始化一个 同步序列号 = P的包到发送方 (接收方->SYN\_RECV)
 *  第三次：发送方收到后，发送一个含ACK位，确认号 = P+1 的包到接收方。 此时连接建立; (发送方->ESTABLISH, 接收方->ESTABLISH)

### 4.四次挥手 ###

*  第一次：主动关闭方发送含FIN位，并初始化一个 同步序列号 = Q 的包到被动方。 (主动方->FIN\_WAIT\_1)
 *  第二次：被动方收到后，发送一个含ACK位且确认号 = Q+1 的包到主动方。 (被动方->CLOSE\_WAIT, 主动方->FIN\_WAIT\_2)
 *  第三次：被动方发送含FIN位，并初始化一个同步序列号 = P 的包到主动方。 (被动方->LAST\_ACK, 主动方->TIME\_WAIT)
 *  第四次：主动方发送最后一个含ACK位且 确认号 = P+1 的包到被动方。 (被动方->CLOSED)

### 5.为什么握手是三次，挥手是四次 ###

*  三次握手原因：**为了应对网络延迟中已失效的连接请求报文段问题**

例子：若client发送的一个连接请求报文段并没有丢失，而是在某个网络节点滞留了。本来这是一个已失效的报文段，而server误以为是一个新的连接请求。于是向client发送确认报文段。若不是“三次握手”，那么只要server发出确认，新的连接就建立了。但实际上client并没有发出连接请求，因此不会理睬server的确认,也不会发送数据。这样就造成了资源的浪费。“三次握手”就能避免这种情况，server没有接到client的确认，连接就没建立。

*  四次挥手原因：

因为TCP连接是全双工的网络协议，允许同时通信的双方同时进行数据的收发，同样也允许收发两个方向的连接被独立关闭，以避免client数据发送完毕，向server发送FIN关闭连接，而server还有发送到client的数据没有发送完毕的情况。所以关闭TCP连接需要进行四次握手，每次关闭一个方向上的连接需要FIN和ACK两次握手。

**之所以不是三次而是四次主要是因为被动关闭方将"对主动关闭报文的确认"和"关闭连接"两个操作分两次进行。以便将缓冲中剩下的数据从输出流发送给主动关闭方。**

### 6.TCP连接状态 ###

*  LISTEN：服务器处于监听状态。
 *  SYN\_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。
 *  SYN\_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。
 *  ESTABLISH：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。
 *  FIN\_WAIT\_1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。
 *  CLOSE\_WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。但是本方是否立即断开连接（发送FIN包）取决于是否还有数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。
 *  FIN\_WAIT\_2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FIN\_WAIT\_2状态。
 *  LAST\_ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。
 *  TIME\_WAIT：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIME\_WAIT状态。

### 7.TCP建立连接及断开连接状态转换 ###

*  客户端：SYN\_SENT -> ESTABLISHED -> FIN\_WAIT\_1 -> FIN\_WAIT\_2 -> TIME\_WAIT
 *  服务端：LISTEN -> SYN\_RCVD -> ESTABLISHED -> CLOSE\_WAIT -> LAST\_ACK -> CLOSED

### 8.FIN\_WAIT\_2, CLOSE\_WAIT 和 TIME\_WAIT状态 ###

FIN\_WAIT\_2:

*  主动断开方接到被动方对自己的确认，但没接到被动方的FIN报文这段期间；
 *  半关闭状态(可以接受数据，不能发送数据)，主要是为了接受被动方缓冲中未发送的数据；

CLOSE\_WAIT:

*  被动关闭连接一方接收到FIN包会立即回应ACK包表示已接收到断开请求。
 *  被动关闭连接一方如果还有剩余数据要发送就会进入CLOSED\_WAIT状态。

TIME\_WAIT:

*  2MSL等待状态
 *  如果客户端直接进入CLOSED状态，如果服务端没有接收到最后一次ACK包会在超时之后重新再发FIN包，此时因为客户端已经CLOSED，所以服务端就不会收到ACK而是收到RST。所以TIME\_WAIT状态目的是防止最后一次握手数据没有到达对方而触发重传FIN准备的。

### 9.OSI七层模型和TCP/IP五层模型 ###

### 应用层 ###

网络服务与最终用户的一个接口。

协议有：**HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP**

### 表示层 ###

数据的表示、安全、压缩。（在五层模型里面已经合并到了应用层）

格式有，**JPEG、ASCll、DECOIC、加密格式等**

### 会话层 ###

建立、管理、终止会话。（在五层模型里面已经合并到了应用层）

**对应主机进程，指本地主机与远程主机正在进行的会话**

### 传输层 ###

定义传输数据的协议端口号，以及流控和差错校验。

协议有：**TCP UDP，数据包一旦离开网卡即进入网络传输层**

### 网络层 ###

进行逻辑地址寻址，实现不同网络之间的路径选择。

协议有：**ICMP IGMP IP（IPV4 IPV6） ARP RARP**

### 数据链路层 ###

建立逻辑连接、进行硬件地址寻址、差错校验等功能。（由底层网络定义协议）

将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正。

### 物理层 ###

建立、维护、断开物理连接。（由底层网络定义协议）

*  OSI七层模型

![format_png][]

*  TCP/IP五层模型

![format_png 1][]

### 10.TCP如何提供可靠数据传输的 ###

*  建立连接（标志位）：通信前确认通信实体存在。
 *  序号机制（序号、确认号）：确保了数据是按序、完整到达。
 *  数据校验（校验和）：CRC校验全部数据。
 *  超时重传（定时器）：保证因链路故障未能到达数据能够被多次重发。
 *  窗口机制（窗口）：提供流量控制，避免过量发送。
 *  拥塞控制：同上。

### 11.超时重传和RTO ###

超时重传：发送端发送报文后若长时间未收到确认的报文则需要重发该报文。可能有以下几种情况：

*  发送的数据没能到达接收端，所以对方没有响应。
 *  接收端接收到数据，但是ACK报文在返回过程中丢失。
 *  接收端拒绝或丢弃数据。

RTO：从上一次发送数据，因为长期没有收到ACK响应，到下一次重发之间的时间，就是重传间隔。

*  通常每次重传RTO是前一次重传间隔的两倍，计量单位通常是RTT。例：1RTT，2RTT，4RTT，8RTT......
 *  重传次数到达上限之后停止重传。

### 12.流量控制原理 ###

*  目的是接收方通过TCP头窗口字段告知发送方本方可接收的最大数据量，用以解决发送速率过快导致接收方不能接收的问题。所以流量控制是点对点控制。
 *  TCP是双工协议，双方可以同时通信，所以发送方接收方各自维护一个发送窗和接收窗。
    
     *  发送窗：用来限制发送方可以发送的数据大小，其中发送窗口的大小由接收端返回的TCP报文段中窗口字段来控制，接收方通过此字段告知发送方自己的缓冲（受系统、硬件等限制）大小。
     *  接收窗：用来标记可以接收的数据大小。
 *  TCP是流数据，发送出去的数据流可以被分为以下四部分：已发送且被确认部分 | 已发送未被确认部分 | 未发送但可发送部分 | 不可发送部分，其中发送窗 = 已发送未确认部分 + 未发但可发送部分。接收到的数据流可分为：已接收 | 未接收但准备接收 | 未接收不准备接收。接收窗 = 未接收但准备接收部分。
 *  发送窗内数据只有当接收到接收端某段发送数据的ACK响应时才移动发送窗，左边缘紧贴刚被确认的数据。接收窗也只有接收到数据且最左侧连续时才移动接收窗口。

### 13.拥塞控制原理 ###

*  拥塞控制目的是防止数据被过多注网络中导致网络资源（路由器、交换机等）过载。因为拥塞控制涉及网络链路全局，所以属于全局控制。控制拥塞使用拥塞窗口。
 *  TCP拥塞控制算法：
    
     *  慢开始 & 拥塞避免：先试探网络拥塞程度再逐渐增大拥塞窗口。每次收到确认后拥塞窗口翻倍，直到达到阀值ssthresh，这部分是慢开始过程。达到阀值后每次以一个MSS为单位增长拥塞窗口大小，当发生拥塞（超时未收到确认），将阀值减为原先一半，继续执行线性增加，这个过程为拥塞避免。
     *  快速重传 & 快速恢复：略
     *  最终拥塞窗口会收敛于稳定值

### 14.流量控制和拥塞控制比较 ###

*  流量控制属于通信双方协商；拥塞控制涉及通信链路全局。
 *  流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。
 *  实际最终发送窗口 = min\{流控发送窗口，拥塞窗口\}。

### 15.ARP地址解析协议 ###

**作用：根据IP地址获取物理(MAC)地址；**

*  主机发送信息时将包含目标IP地址的ARP请求广播到局域网络上的所有主机，并接收返回消息，以此确定目标的物理地址；收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。
 *  ARP建立在各个主机互相信息的基础上，局域网络上的主机可以自主发送ARP应答消息，其他主机收到应答报文时不会检测该报文的真实性就会将其记入本机ARP缓存；
 *  ARP欺诈：攻击者可以向某一主机发送伪ARP应答报文，使其发送的信息无法到达预期的主机或到达错误的主机，这就构成了一个

对比：

**RARP：反向地址转换协议**

**作用：允许局域网的物理机器从网关服务器的ARP表或者缓存上请求其IP地址。局域网网关路由器里一个表以映射物理地址(MAC)和IP地址。**

**工作过程：**

1.  网络上的每台设备都会有一个独一的硬件地址，通常是由设备厂商分配的MAC地址。PC1从网卡上读取MAC地址，然后在网络上发送一个RARP请求的广播数据包，请求RARP服务器回复该PC的IP地址。
2.  RARP服务器收到了RARP请求数据包，为其分配IP地址，并将RARP回应发送给PC1。
3.  PC1收到RARP回应后，就使用得到的IP地址进行通讯。

### 16.TCP和UDP是否可以使用相同的端口？ ###

*  可以！使用TCP/UDP 协议的上层应用程序可以分配重复的端口号； 如下图所示：
 *  ![SouthEast][]

**每个数据帧到达主机时，会从数据链路层->网络层->传输层 层层解析检查报文首部中的协议标识，以确认接收数据的协议，这个过程称作分用，所以TCP/UDP协议的上层应用程序可以分配重复的端口号！**

### HTTP相关 ###

### URI 统一资源表示符 ###

URI 包含 URL 和 URN。

![format_png 2][]

### HTTP方法： ###

## GET ##

> 获取资源

当前网络请求中，绝大部分使用的是 GET 方法。

## HEAD ##

> 获取报文首部

和 GET 方法类似，但是不返回报文实体主体部分。

主要用于确认 URL 的有效性以及资源更新的日期时间等。

## POST ##

> 传输实体主体

POST 主要用来传输数据，而 GET 主要用来获取资源。

## PUT ##

> 上传文件

由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。

## PATCH ##

> 对资源进行部分修改

PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

## DELETE ##

> 删除文件

与 PUT 功能相反，并且同样不带验证机制。

## OPTIONS ##

> 查询支持的方法

查询指定的 URL 能够支持的方法。

会返回 `Allow: GET, POST, HEAD, OPTIONS` 这样的内容。

## CONNECT ##

> 要求在与代理服务器通信时建立隧道

使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

## TRACE ##

> 追踪路径

服务器会将通信路径返回给客户端。

发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。

通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。

#  #

### 常见HTTP状态码： ###

*  **200：成功。**
 *  **204：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。**
 *  **206：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。**
 *  **301：内容已经移动。永久性重定向**
 *  **302：临时性重定向**
 *  **400：请求不能被服务器理解。请求报文中存在语法错误。**
 *  **401：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。**
 *  **403：无权访问该文件。请求被拒绝。**
 *  **404：不能找到请求文件。**
 *  **500：服务器内部错误。**
 *  **501：服务器不支持请求的方法。**
 *  **505：服务器不支持请求的版本。**

### HTTP1.0和HTTP1.1区别 ###

*  **长连接和短连接**：HTTP1.0是短连接，每次请求都需要创建连接； HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟；
 *  **host字段(虚拟主机)：**HTTP1.0认为每台服务器都绑定一个唯一IP地址，请求消息中的URL并没有传递主机名；随着虚拟主机技术的发展，一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址；
 *  **带宽优化及网络连接的使用：**HTTP1.0中存在浪费带宽的现象，例如客户端只需要某个对象一部分，服务器却将整个对象回传了； HTTP1.1在请求头引入了range头域，允许只请求资源的某个部分；
 *  **缓存处理：**在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

### HTTP2.0和HTTP1.X相比的新特性 ###

*  **新的二进制格式**（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
 *  **多路复用**（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
 *  **header压缩**，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
 *  **服务端推送**（server push），同SPDY一样，HTTP2.0也具有server push功能。

### HTTPS ###

HTTP 有以下安全性问题：

*  使用明文进行通信，内容可能会被窃听；
 *  不验证通信方的身份，通信方的身份有可能遭遇伪装；
 *  无法证明报文的完整性，报文有可能遭篡改。

HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。

通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

## **输入一个网址后的全过程：** ##

*  解析URL
 *  DNS查询：（根据域名查询IP地址） **DNS域名解析时用的是UDP协议**
    
     *  浏览器缓存查询：浏览器检查域名是否在缓存中
     *  操作系统本地host缓存查找网址对应DNS信息
     *  路由器缓存查找
     *  本地IPS（服务商）的DNS服务器查找 —— **请求的域名基本上能在这里找到**
     *  根域名服务器查询
 *  **DNS查询请求DNS服务器时需要用到ARP协议，设置目的IP地址为DNS服务器IP地址，发送IP数据包。如果ARP缓存中没有相关数据，就发送ARP广播。 这样层层传递并且在各层ARP缓存表中记录。**
 *  DNS服务单元将域名解析成IP地址，产生回应报文， 传递回主机。 DNS回应报文->UDP->IP->MAC->我的主机；
 *  得到域名对应的IP地址。 HTTP请求使用TCP进行传输的，三次握手建立连接；
 *  发送和收取数据：一个数据包传输过程如下，以HTTP的方法请求为例：
    
     *  浏览器向域名对应的IP地址发出GET方法报文；
     *  该GET方法报文通过TCP->IP（DNS）->MAC（ARP）->网关->目的主机；
     *  目的主机收到数据帧，通过IP->TCP->HTTP，HTTP协议单元会回应HTTP协议格式封装好的HTML形式数据；
     *  该HTML数据通过TCP->IP（DNS）->MAC（ARP）->网关->我的主机；
     *  解析 HTML，渲染展示
 *  数据传输完成后四次挥手断开连接

[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNzA1NzI4LzIwMTYwNC83MDU3MjgtMjAxNjA0MjQyMzQ4MjQwODUtNjY3MDQ2MDQwLnBuZw?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWFnZXMyMDE1LmNuYmxvZ3MuY29tL2Jsb2cvNzA1NzI4LzIwMTYwNC83MDU3MjgtMjAxNjA0MjQyMzQ4MjcxOTUtMTQ5MzEwNzQyNS5wbmc?x-oss-process=image/format,png
[SouthEast]: https://img-blog.csdn.net/20131014140434078?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZmVydm9yX2hlYXJ0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9naXRodWIuY29tL0N5QzIwMTgvQ1MtTm90ZXMvcmF3L21hc3Rlci9ub3Rlcy9waWNzLzg0NDFiMmM0LWRjYTctNGQ2Yi04ZWZiLWYyMmVmY2NhZjMzMS5wbmc?x-oss-process=image/format,png