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

1.网络编程一般步骤：

• TCP：

服务端：socket绑定成功后开始监听、接收到数据后发送数据并关闭连接；客户端：socket连接成功后发送或接收数据并关闭连接

• UDP:

1. 服务端：使用 socket 网络连接并绑定指定服务器端口后（即 socket.bind），随后分别通过 recvfrom 和 sendto 接收客户端发送过来的消息（即 recvfrom），并在所有操作完成后关闭该网络连接（即 close）。
2. 客户端：通过 socket 发送消息至 recvfrom 端口并接收来自 sendto 端口的消息后（即 recvfrom/sendto），在完成所有通信流程后关闭该网络连接（即 close）。

2.TCP和UDP的区别：

• TCP面向连接（建立连接的过程），在通信前双方需完成必要的准备工作；而UDP则无需任何连接信息，在无需连接的情况下即可进行通信。
• TCP借助序号机制保证数据的有序到达，在面对网络波动时会采取重传策略以确保数据完整性；而UDP仅能尽力而为，并不具备严格的可靠性保障。
• TCP基于字节流进行传输，在接收端能够对接收到的数据包进行重新组织以保证逻辑顺序的正确性；而UDP则提供灵活的数据报服务。

3.三次握手

由主动发起连接的一端向另一端发送含SYN位的报文，并设置同步序列号为S；
当接收端收到该报文后会回复包含ACK位、SYN位及确认号为S+1的报文，并设置同步序列号为P；
当发送端接收到该报文后会回复包含ACK位及确认号为P+1的响应报文；此时双方完成连接建立；

4.四次挥手

• 第一次：主动关闭方式接收并带有FIN标志的数据包（同步序列号=Q）传递给被动关闭方式。
  • 第二次：被动关闭方式接收到该数据包后会立即返回一个带有确认码为Q+1的ACK标志给主动关闭方式。
  • 第三次：当被动关闭方式检测到错误时会发送一个包含FIN标志并重新初始化同步序列号为P的数据包给主动关闭方式。
  • 第四次：当主动关闭方式确认所有数据传输完成时会发出带有最终确认码P+1的ACK数据包给被动关闭方式。

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

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

若一个连接请求报文段在传输过程中未丢失，在网络节点上等待接收原本就是已经失效的报文段。然而由于服务器错误地认为这是一个新到达的连接请求而进行了响应处理。于是向客户端发送确认报文段。如果没有采用三次握手机制，则只要服务器发送确认信号,新的连接就不会建立起来。然而实际上客户端并没有发起任何连接请求操作,因此不会对服务器的确认做出回应也不会发送任何数据包过来。从而导致资源浪费的情况发生。而采用三次握手机制则能有效避免这种情况的发生使得服务器不会收到客户端的确认信号从而也就无法建立新的连接关系

• 四次挥手原因：

由于TCP连接作为全双工网络协议的特点，在支持双向的数据接收与发送操作的同时，并不会影响两端独立处理断开情况的能力。为了避免在客户端完成数据发送后立即向服务器发出FIN标志以关闭连接而导致服务器在等待状态下出现未收到全部数据的情况（即服务器可能仍有剩余待发送的数据），因此实现对两端断开状态的有效管理，则必须经过四次握手机制的操作流程。具体而言，在完成一个方向上的断开操作时，则需要执行FIN和ACK两次确认（ACK应答）的动作才能确保另一端能够正确处理当前的状态变化。

因此是第四次而非第三次的原因在于被动关闭方依次完成了"对主动关闭报文的确认"以及"关闭连接"这两个操作以确保缓冲区剩余的数据能够通过输出流传递给主动关闭方

因此是第四次而非第三次的原因在于被动关闭方依次完成了"对主动关闭报文的确认"以及"关闭连接"这两个操作以确保缓冲区剩余的数据能够通过输出流传递给主动关闭方

6.TCP连接状态

LISTEN：服务器处于监听状态。

SYN_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。

SYN_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。

ESTABLISH：表示连接建立。客户端发送最后一个ACK包后会进入此状态，在服务端接收ACK包后也会进入此状态。

FIN_WAIT_1 表示在 TCP/IP 协议中，在客户端（通常是客户端机器）发送出了 FIN 报文之后会进入连接终止的状态。服务器端则需要等待收到客户端的 ACK 报文才能确认连接建立完成。

CLOSE_WAIT阶段：当服务器接收并响应客户机发出的 FIN 包时进入等待关闭的状态。当服务器接收并响应客户机发出的 FIN 包时会立即返回 ACK 报文以确认客户端已发起断开请求。若当前无数据待发送则无需立即发出 FIN 包否则应在发出 FIN 包前切换到无数据状态以确保不会影响后续的数据传输过程

FIN_WAIT_2：处于半连接状态，在此情况下有一方发送关闭请求（即一方要求关闭连接），等待对方发送关闭信号。客户端成功接收服务器返回的ACK包，并未立即收到服务端发送的FIN包（即转入了FIN_WAIT_2状态）。

服务端发送最后一方FIN包以期待客户端ACK响应，并处于此状态

该客户端接收到服务端发送的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七层模型

• TCP/IP五层模型

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

• 建立连接（标志位）：确保通信实体在建立连接前处于有效状态。
  • 序号机制（序号、确认号）：通过计算校验和确保数据按顺序传输并包含确认信息。
  • 数据校验（校验和）：通过计算校验和来保证数据完整性。
  • 超时重传（定时器）：利用定时器设置超时时间以实现重传机制。
  • 窗口机制（窗口）：通过窗口大小控制发送速率以避免拥塞。
  • 拥塞控制：同上。

11.超时重传和RTO

当发生超时现象时，则需对相关数据包进行重新发送

• 发送的数据未能抵达对方的接收端导致未得到回应。
• 接收到的数据因未发送确认的ACK报文而受阻。
• 接收端选择性地将这些异常情况以拒绝或丢弃的形式处理。

RTO：在上次发送的数据之后因长时间未收到ACK响应至下次再发所需的时间即为重传间隔

• 一般情况下，在每次重传中，RTO会翻倍，在这种机制下所使用的计量单位通常是RTT（Round-Trip Time）。例如：1个RTT、2个RTTs、4个RTTs、8个RTTs……
  • 当达到预先设定的最大重传次数后则不再进行重传。

12.流量控制原理

• 目的是旨在接收方通过TCP头中的窗口字段向发送方报告其可接收的最大数据量，并以此实现对传输速率的有效管理。
• 因此流量控制机制实现了双方的数据传输互不干扰。
• TCP作为双工通信协议，在保证双方能够同时进行数据传输的同时，
• 每一方都需要维护自己的发-windows（即发送窗口）和收-windows（即接收窗口）。
• 在具体实现中：
  • 发送窗：用来限制当前时间段内能够被发送出去的数据总量，
  • 其大小由接收到的TCP报文中窗口字段所指示的数据量来确定。
  • 接收窗：则用于标识当前时间段内能够被接收的数据总量。
• 在实际应用中，
• 发送出去的数据流可被划分为四个部分：
  • 已经被成功发送并得到确认的部分；
  • 已经被成功发送但尚未得到确认的部分；
  • 未被成功发送但仍有潜力可发的部分；
  • 还处于不可 sender状态的部分。
• 其中发-windows = Ack-received已送未确认的数据 + 未发但可 sender的数据。
• 同样地，
• 接收到的数据流也可以划分为三个阶段：
  • 已经完全被接受的部分；
  • 还有潜力被接受但尚未连续接受的部分；
  • 完全未被接受且准备停止接受的部分。
• 其中收-windows = 未连续接受但仍有接收到位的部分。
• 在动态管理过程中，
• 当接收到某段数据并获得其Ack响应时，
• 才会相应地移动发-windows左边缘至刚被确认的位置。
• 类似地，
• 只有当接收到连续不断的最左侧数据块时，
• 才会移动收-windows右边缘至最左侧连续位置处。

13.拥塞控制原理

• 拥堵控制的主要目标是防止大量数据被接入网络而导致网络资源（如路由器、交换机等）负担过重。
• 由于该机制考虑了整个网络链路的全局状态特性,因此属于一种全局型的流量管理方法。
• 为了实现有效的流量调节,该算法采用了一种称为"慢开始"的过程,具体分为两个阶段:首先通过试探法确定当前网络的负载水平,在此基础上逐步扩大拥塞窗口;当达到预设阈值SSThresh后,则以每个Minimum Segment Size(MSS)为单位继续增大窗口大小。
• 如果检测到发送方长时间未收到确认信号(即发生拥塞),则将阈值减半,随后继续按线性方式递增。
• 最终系统会稳定在某个特定的拥塞窗口大小。

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

• 流量控制涉及双方协商过程；拥塞控制关注整个通信链路状况。
  • 流量控制中各参与方需设置发送窗与接收窗；对于任一方而言接收窗大小依据自身情况确定。
    发送窗大小则由对方通过接收到的数据报文中的窗口值来动态调整。
  • 实际最终发送窗口 = min{流控发送窗口, 拥塞窗口}。

15.ARP地址解析协议

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

• 主机在发送信息时会向局域网络中的所有主机发送包含目标IP地址的 ARP 请求包，并通过接收到这些响应包来确定目标机器的实际物理地址；一旦接收到响应包后会将该 IP 地址与其对应的物理地址记录于本地 ARP 缓存中并予以保留一段时间以便后续查询时不需重新计算。
• ARP 建立在各台主机间相互提供的信息基础之上 在局域网内的各台主机均可自主生成相应的 ARP 应答数据包；当另一台宿主接收到来自某台设备发出的所有类 ARP 应答数据包时 并不会检测其真实性从而将其记录于本地 ARP 缓存中。
• ARP 恶意攻击者可向特定的目标宿主发 送伪 ARP 应答数据包 使这些数据无法成功到达预期的目标宿主或被错误地路由至其它宿主造成通信故障。

对比：

RARP：反向地址转换协议

作用：局域网中的物理设备可从Netgate服务器的ARP缓存或直接查询获取本地网络的IP地址信息。在局域网路由器内部设置了一个数据表用于将MAC地址与对应的网络IP地址进行关联映射。

工作过程：

网络上的每台设备都有一个独特的硬件地址；通常是由设备厂商分配使用的MAC地址。
PC1通过网卡获取其对应的MAC地址，并向网络中发射了一个广播型的RARP请求数据包。
当PC1接收到RARP应答后，则利用获取到的IP地址来进行通讯。

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

可以通过TCP/UDP协议的上层应用程序来实现重复端口号的分配； 如下图所示

每当一个数据帧抵达主机时,它会依次经过数据链路层、网络层和传输层,在每一层次解析报文首部中的协议标识以识别接收到的数据.这一过程被称为分用;因此,在TCP/UDP协议下,上一层应用程序能够分配相同的端口号给不同的连接.

HTTP相关

URI 统一资源表示符

URI 包含 URL 和 URN。

HTTP方法：

GET

获取资源

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

HEAD

获取报文首部

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

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

POST

传输实体主体

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

PUT

上传文件

因未配备验证功能，在线用户不受限制地上传文件内容时会必然导致安全隐患；不宜采用此方案。

PATCH

对资源进行部分修改

除了替换整个对象外还可以通过PATCH实现局部调整。不仅能够作为完整的替代方案使用还允许进行局部调整。

DELETE

删除文件

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

OPTIONS

查询支持的方法

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

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

CONNECT

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

采用SSL/TLS协议将通信内容加密并使其通过网络通道传递

TRACE

追踪路径

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

每次发送请求时，在Max-Forwards头部字段中设置为某个数值，并在经过每个服务器后递减1次；直至该值降为零后则停止传输。

通常情况下，并不会采用TRACE技术，并且容易遭受XST攻击（Cross-Site Tracing, 跨站追踪）。

常见HTTP状态码：

• 200: 该状态码表示请求已成功完成。（增加"已"字使表述更详细）
• 204: 返回的响应报文未包含实体主体部分。（将"已经成功处理"改为"返回"并调整语序）
• 206: 表示客户端进行了范围请求操作。（将"进行了"改为"进行"并优化表达）
• 301: 指定内容已永久转移。（将"已经移动"改为"转移"并简化表达）
• 302: 该指令执行临时性重定向。（使用代词代替名词使表述更灵活）
• 4xx: 表示服务器无法理解请求内容。（使用代词替代具体数字使描述更简洁）
• 4xx: 该状态码指示客户端需提供认证信息（BASIC或DIGEST认证）。（补充必要修饰词使描述更完整）
• 4xx: 当前权限不足以访问指定资源。（将否定关系融入主语后半部分）
• [...]: 无法找到指定文件的状态码。（替换重复出现的表述使其更简洁）
• [...]: 服务器内部发生故障导致拒绝响应。（补充修饰使描述更完整）
• [...]: 该方法不支持当前所使用的请求方法。（补充修饰使描述更完整）
• [...]: 版本不符导致拒绝响应。（补充修饰使描述更完整）

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相比的新特性

新的二进制表示方案

多路复用（MultiPlexing）也被称作连接共享机制。这也是将多个数据流整合到单个传输介质的技术手段之一。每个请求都分配一个唯一的标识符，在这样的连接中可以允许多个请求同时存在。各个请求可以在同一时间混合地存在于同一个通道中，在接收端可以通过每个 request 的唯一标识将其重新路由至相应的服务队列或处理任务。

基于此方法的技术特点可以看出

服务端推送 （server push），同SPDY一样，HTTP2.0也具有server push功能。

HTTPS

HTTP 有以下安全性问题：

• 采用公开信道进行通信，在这种情况下通信内容可能会遭到窃取；
• 未对通信双方的身份进行核实，在这种情况下通信方的身份可能受到冒充；
• 在这种情况下无法确保数据包的完整性，在这种情况下数据包可能遭到篡改。

HTTPS并非新协议，并非如此；而是通过先与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，渲染展示
• 数据传输完成后四次挥手断开连接