layout: post
title: 八股总结（二）计算机网络与网络编程
description: 八股总结（二）计算机网络与网络编程
tag: 八股总结

文章目录

计算机网络
- 网络模型
- - 网络体系结构
  - 在浏览器输入一个网址后回车，背后都发生了什么？
- 数据链路层
- - 地址解析ARP（address resolution protocol）协议
- 网络层
- - 网际控制报文协议ICMP（internet control message protocol）
- 传输层
- - TCP协议
  - - 什么是TCP协议？
    - 什么是TCP粘包/拆包？发生的原因？解决方法？
    - TCP和UDP的区别
    - TCP和UDP的应用场景？
    - 为什么TCP有「首部⻓度」字段，UDP没有？
    - TCP报文结构
    - TCP建立连接为什么是3次握手，而不是2次或者4次？
    - SYN攻击（DDOS攻击）原理及避免方法
    - TCP连接4挥手断开连接
    - 服务器出现了大量的TIME_WAIT或CLOSE_WAIT可能是什么原因，该怎么办？
    - TCP重传机制
    - TCP滑动窗口
    - 流量控制
    - 拥塞控制
  - UDP协议
- 应用层
- - HTTP
  - - session，cookie，token的应用与区别
  - HTTP常见字段有哪些？
  - - HTTP状态码
    - GET和POST的区别？
    - HTTP和HTTPS的区别？
    - HTTPS解决了HTTP哪些问题，是怎么解决的？
    - SLL/TLS协议基本流程
    - HTTP/1.1、HTTP/2、HTTP/3演变
  - Web Socket协议
  - 域名解析协议（DNS，Domain Name System）
  - - 为什么域名解析用UDP协议？
  - 动态主机配置协议（DHCP，Dynamic Host Configuration Protocol）
Linux网络编程
- TCP的socket编程

计算机网络

网络模型

网络体系结构

OSI七层模型是法律上规定的国际标准，但TCP/IP体系占据了市场，是实际上的国际标准，为了方便理解，由将TCP/IP四层的结构中的网络接口层分为了物理层和数据链路层。

物理层的数据为比特流，数据链路层为帧，网络层为包，传输层为数据段。
各层常用的网络协议有哪些？
- 数据链路层：ARP（地址解析协议）
- 网络层：IP协议、ICMP（网际控制报文协议）、VPN、内部网关协议（如路由信息协议RIP）、外部网关协议（如边界网关协议BGP）
- 传输层：TCP（传输控制协议）、UDP（用户数据报协议）
- 应用层：DNS（域名解析），FTP（文件传输），DHCP（动态主机配置协议），HTTP（超文本传输协议）

网络协议栈数据报文发送与接收过程中的变化：

在浏览器输入一个网址后回车，背后都发生了什么？

查看浏览器缓存，如果没有
向DNS服务器发送DNS请求（采用的是UDP协议），查询本地DNS服务器。
如果本地DNS查不到，就从根域名服务器，递归的查询每一级域名服务器，直到查到为止。
有了DNS解析结果，我们就有了服务器的ip地址，以及默认的端口号了，http默认端口号是80，https默认端口号443。
首先尝试使用http协议，调用Socket经过三次握手建立TCP连接，开始传送数据，如果正好采用http协议通信，直接返回。
如果不是http协议，服务器会返回一个5开头的重定向消息，告诉我们应该使用https，于是TCP四次挥手关闭对端口80的连接。
TCP三次握手尝试连接443端口，采用SSL/TSL握手，沟通好双方使用的数字证书认证、加密和检验算法。
确认无误后，开始通信，服务器会返回你所要访问网址的一些数据，在此过程中会将界面进行渲染，使得我们能够看到色彩斑斓的网页。

数据链路层

通俗来讲，数据链路层完成的是从目的主机所在路由器（目的MAC地址）到本地路由器（源MAC地址）的连接。

地址解析ARP（address resolution protocol）协议

ARP地址解析协议只能在单个数据链路段中使用，用于将IP地址解析为对应的MAC地址。

网络层

通俗来讲，网络层完成目的主机和本地主机之间的连接。

网络层最常用的就是IP协议（Internet protocol），将传输层的报文作为数据部分再加上IP包头组装成IP报文，如果IP报文超过MTU（以太网中一般为1500字节）就会再次进行分片，得到一个即将发送到网络的IP报文。

IP 地址分成两种意义：
⼀个是⽹络号，负责标识该 IP 地址是属于哪个⼦⽹的；
⼀个是主机号，负责标识同⼀⼦⽹下的不同主机。

网际控制报文协议ICMP（internet control message protocol）

为了有效转发IP数据报和提高交付成功的机会，网际层使用了网际控制报文协议ICMP，使得主机和路由器可以使用ICMP来发送差错报告报文和询问报文，ICMP报文被封装在IP数据报中发送。
ICMP差错报文分为以下5种：

传输层

网络层已经解决了主机与主机之间的通信，而传输层要解决的是两个主机各自进程间进行通信的问题。

TCP协议

什么是TCP协议？

TCP是面向连接的、可靠的、基于字节流的传输层通信协议。

面向连接：一定是一对一才能连接，不像UDP协议可以一台主机同时向多个主机发送消息。也就是说TCP只能一对一，不能像UDP那样一对多。
可靠的：无论网络链路中出现怎样的链路变化，TCP都可以保证一个报文一定能够到达接收端；
字节流：消息是无边界的，所以无论我们的消息有多大都可以进行传输，而且消息是有序的，当前一个没有收到的时候，即使它先收到了后边的字节，那么也不能扔给应用层去处理，同时对重复的报文会自动丢弃。

什么是TCP粘包/拆包？发生的原因？解决方法？

一个完整的业务可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这个就是TCP的拆包和粘包问题。

原因
1、应用程序写入数据的字节大小大于套接字发送缓冲区的大小.

2、进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)

3、以太网的payload大于MTU进行IP分片。（ MTU指：一种通信协议的某一层上面所能通过的最大数据包大小。）

解决方案：
1、增加消息长度字段。

2、在包尾部增加回车或者空格符等特殊字符进行分割

3、将消息分为消息头和消息尾

4、使用其它复杂的协议，如RTMP协议等。

TCP和UDP的区别

连接：TCP是面向连接的传输层协议，传输数据前需要先建立连接，而UDP是不需要连接，即刻传输数据。
服务对象：TCP是一对一两点服务，UDP支持一对一、一对多和多对多
可靠性：TCP是可靠交付数据，数据可以无差错、不丢失、不重复、按需到达；UDP是尽最大努力交付，不保证可靠交付数据
拥塞控制、流量控制：TCP有拥塞控制和流量控制机制，保证数据传输的安全性，UDP则没有，即便是网络非常拥堵，也不会影响UDP的发送速率。
首部开销：TCP首部长，而UDP首部只有8个字节
传输方式：TCP是流式传输，没有边界，但是保证顺序和可靠；UDP是一个包一个包的发送，是有边界的，但是可能会丢包和乱序。

TCP和UDP的应用场景？

由于TCP是面向连接的，能够保证数据的可靠性交付，因此经常被用于FTP文件传输，HTTP、HTTPS

由于UDP是面向无连接的，它可以随时发送数据，加上UDP本身的处理既简单又高效，因此经常用于包总量较少的通信，如DNS、SNMP等，视频，音频等多媒体通信，广播通信。

为什么TCP有「首部⻓度」字段，UDP没有？

原因是 TCP 有可变⻓的「选项」字段，⽽ UDP 头部⻓度则是不会变化的，⽆需多⼀个字段去记录 UDP 的⾸部⻓度。

TCP报文结构

端口号：TCP是进程与进程间的通信，因此，头部两端是16位的源端口号和16位的目的端口号
序列号（SEQ）：在建立连接时由计算机生成的随机数作为其初始值，通过SYN包传递给接收端主机，每发送一次数据，就累加一次该数据字节数的大小，用来解决网络包乱序问题。
确认应答号（ACK）：指下一次期望收到数据的序列号，发送端收到这个应答以后可以认为在这个序号以前的数据都已经被正常接收，用来解决不丢包的问题。
控制位：ACK：该位为 1 时，「确认应答」的字段变为有效，TCP 规定除了最初建⽴连接时的 SYN 包之外该位必须设置为 1。
RST：该位为 1 时，表示 TCP 连接中出现异常必须强制断开连接。
SYN：该位为 1 时，表示希望建⽴连接，并在其「序列号」的字段进⾏序列号初始值的设定。
FIN：该位为 1 时，表示今后不会再有数据发送，希望断开连接。当通信结束希望断开连接时，通信双⽅的主机之间就可以相互交换 FIN 位为 1 的 TCP 段。
窗口大小：用于拥塞控制
校验和：差错控制
紧急指针：仅当前面的 URG 控制位为 1 时才有意义。它指出本数据段中为紧急数据的字节数，占 16 位。当所有紧急数据处理完后，TCP 就会告诉应用程序恢复到正常操作。即使当前窗口大小为 0，也是可以发送紧急数据的，因为紧急数据无须缓存。
选项（Option）：长度不定，但长度必须是 32bits 的整数倍。
数据

TCP建立连接为什么是3次握手，而不是2次或者4次？

三次握手才可以阻止重复历史连接的初始化（首要原因）
三次握手才可以同步双方的初始序列号
三次握手才可以避免资源浪费

客户端连续发送多次SYN建立连接的报文，在网络拥堵情况下，一次旧的SYN报文比新的SYN报文到达了服务端，那么此时服务端就会返回一个SYN + ACK报文给客户端，客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列化过期或者超时），那么客户端就会发送RST报文给服务端，表示终止这一次连接。

如果是两次握手，就不足以判断当前连接是否为历史连接。

SYN攻击（DDOS攻击）原理及避免方法

我们都知道 TCP 连接建⽴是需要三次握⼿，假设攻击者短时间伪造不同 IP 地址的 SYN 报⽂，服务端每接收到⼀个 SYN 报⽂，就进⼊ SYN_RCVD 状态，但服务端发送出去的 ACK + SYN 报⽂，⽆法得到未知 IP 主机的 ACK 应答，久⽽久之就会占满服务端的 SYN 接收队列（未连接队列），使得服务器不能为正常⽤户服务。

TCP连接4挥手断开连接

客户端打算关闭连接，此时会发送⼀个 TCP ⾸部 FIN 标志位被置为 1 的报⽂，也即 FIN 报⽂，之后客户端进⼊ FIN_WAIT_1 状态。
服务端收到该报⽂后，就向客户端发送 ACK 应答报⽂，接着服务端进⼊ CLOSED_WAIT 状态。
客户端收到服务端的 ACK 应答报⽂后，之后进⼊FIN_WAIT_2 状态。
等待服务端处理完数据后，也向客户端发送 FIN 报⽂，之后服务端进⼊ LAST_ACK 状态。
客户端收到服务端的 FIN 报⽂后，回⼀个 ACK 应答报⽂，之后进⼊ TIME_WAIT 状态
服务器收到了 ACK 应答报⽂后，就进⼊了 CLOSED 状态，⾄此服务端已经完成连接的关闭。
客户端在经过 2MSL ⼀段时间后，⾃动进⼊ CLOSED 状态，⾄此客户端也完成连接的关闭。

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存时间

服务器出现了大量的TIME_WAIT或CLOSE_WAIT可能是什么原因，该怎么办？

首先可以通过下面的命令统计当前系统中time_wait或close_wait的数量

ss- tan state time-wait | wc -l

ss 命令可以用来获取 socket 统计信息，它显示的内容和 netstat 类似。但 ss 的优势在于它能够显示更多更详细的有关 TCP 和连接状态的信息，而且比 netstat 更快。

一般而言，TIME_WAIT状态对CPU的开销影响不会太大，只是多占用了端口，使得这些端口短时间内得不到释放。

如果执意想减小这些影响，可以有以下三个方法：

禁用socket延迟关闭
通常情况当close被调用时，SOCKET需要延迟关闭(lingering)，在内核buffers中的残留数据将会发送到远程地址，同时，socket会切换到TIME-WAIT状态。如果禁用此选项，则调用close之后，底层也会关闭，不会将Buffers中残留数据未发送的数据继续发送。
禁用net.ipv4.tcp_tw_reuse
这个选项有什么作用呢？根据名称也能猜到，这个选项可以重用TIME_WAIT状态下的连接。默认情况下TIME_WAIT状态的时间是60s(linux中)，而如果开启了这个选项，当系统需要发起新的outgoing connection时，如果新的时间戳比之前TIME_WAIT连接的时间戳大的话（大于1s），则可直接复用原有的TIME_WAIT连接。即：TIME-WAIT状态的连接，仅仅1秒后就可以被重用了。
禁用net.ipv4.tcp_tw_recycle
这个选项同样依赖时间戳选项，同样更加选项名称也能猜到，这个选项可以加快TIME_WAIT状态连接的回收时间（不开启默认是60s）。如果开启了这个选项，则TIME_WAIT的回收时间变为一个3.5个RTO（超时重传时间），当然这个时间是随网络状态动态变化的，有RTT计算而来。这个选项对所有的TIME_WAIT状态都有影响，包括incoming connections和 outgoing connections。所以开启这个选项，对客户和服务端都会产生影响。

CLOSE_WAIT是状态太多可能是由于服务端迟迟没有发送FIN，所导致的，可能的原因有两个

在对方关闭连接后，自身程序里没有检测（被动方）
主动方忘了需要关闭连接，于是整个资源就一直被程序占用着。

因此大量close_wait的出现可能是程序中，没有及时关闭进程所导致的，需要仔细检查程序中是否忘记检测关闭状态，是否检测到关闭，但自身的关闭指令被延迟或遗忘了。

TCP重传机制

TCP 针对数据包丢失的情况，会⽤重传机制解决。常见的重传机制如下：

超时重传：是在发送数据时，设定⼀个定时器，当超过指定的时间后，没有收到对⽅的 ACK 确认应答报⽂，就会重发该数据，也就是我们常说的超时重传。（发送数据包丢失和对方ACK数据包丢失都会触发超时重传）

RTO（Retransmission Timeout 超时重传时间）根据RTT（Round-Trip Time ，往返时延/）确定。

快速重传
快速重传的⼯作⽅式是当收到三个相同的 ACK 报⽂时，会在定时器过期之前，重传丢失的报⽂段。

快速重传机制只解决了⼀个问题，就是超时时间的问题，但是它依然⾯临着另外⼀个问题。就是重传的时候，是重
传之前的⼀个，还是重传所有的问题。
⽐如对于上⾯的例⼦，是重传 Seq2 呢？还是重传 Seq2、Seq3、Seq4、Seq5 呢？因为发送端并不清楚这连续的
三个 Ack 2 是谁传回来的。
SACK （ Selective Acknowledgment 选择性确认）重传
这种⽅式需要在 TCP 头部「选项」字段⾥加⼀个 SACK 的东⻄，它可以将缓存的地图发送给发送⽅，这样发送⽅就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
如下图，发送⽅收到了三次同样的 ACK 确认报⽂，于是就会触发快速重发机制，通过 SACK 信息发现只有200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进⾏重复。如果要⽀持 SACK ，必须双⽅都要⽀持。在 Linux 下，可以通过 net.ipv4.tcp_sack 参数打开这个功能（Linux2.4 后默认打开）。

4. Duplicate SACK ⼜称 D-SACK ，其主要使⽤了 SACK 来告诉「发送⽅」有哪些数据被重复接收了。
例子1：

「接收⽅」发给「发送⽅」的两个 ACK 确认应答都丢失了，所以发送⽅超时后，᯿传第⼀个数据包（3000 ~
3499）
于是「接收⽅」发现数据是重复收到的，于是回了⼀个 SACK = 3000~3500，告诉「发送⽅」 3000~3500 的数据早已被接收了，因为 ACK 都到了 4000 了，已经意味着 4000 之前的所有数据都已收到，所以这个 SACK就代表着 D-SACK 。
这样「发送⽅」就知道了，数据没有丢，是「接收⽅」的 ACK 确认报⽂丢了。

例子2：

数据包（1000~1499）被⽹络延迟了，导致「发送⽅」没有收到 Ack 1500 的确认报⽂。
⽽后⾯报⽂到达的三个相同的 ACK 确认报⽂，就触发了快速重传机制，但是在重传后，被延迟的数据包（1000~1499）⼜到了「接收⽅」；
所以「接收⽅」回了⼀个 SACK=1000~1500，因为 ACK 已经到了 3000，所以这个 SACK 是 D-SACK，表示收到了重复的包。这样发送⽅就知道快速重传触发的原因不是发出去的包丢了，也不是因为回应的 ACK 包丢了，⽽是因为⽹络延迟了。

可见使用D-SACK的好处是：

可以让发送方知道，是发出的包丢了，还是接收方回应的ACK包丢了；
可以知道是不是发送包的数据包被网络延迟了

在 Linux 下可以通过 net.ipv4.tcp_dsack 参数开启/关闭这个功能（Linux 2.4 后默认打开）。

TCP滑动窗口

#1 是已发送并收到 ACK确认的数据：1~31 字节
#2 是已发送但未收到 ACK确认的数据：32~45 字节
#3 是未发送但总⼤⼩在接收⽅处理范围内（接收⽅还有空间）：46~51字节
#4 是未发送但总⼤⼩超过接收⽅处理范围（接收⽅没有空间）：52字节以后

TCP 滑动窗⼝⽅案使⽤三个指针来跟踪在四个传输类别中的每⼀个类别中的字节。其中两个指针是绝对指针（指特
定的序列号），⼀个是相对指针（需要做偏移）。

接收部分如上图所示，其中三个接收部分，使⽤两个指针进⾏划分:
RCV.WND ：表示接收窗⼝的⼤⼩，它会通告给发送⽅。
RCV.NXT ：是⼀个指针，它指向期望从发送⽅发送来的下⼀个数据字节的序列号，也就是 #3 的第⼀个字节。
指向 #4 的第⼀个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND ⼤⼩的偏移ᰁ，就可以指向 #4 的
第⼀个字节了。

流量控制

发送⽅不能⽆脑的发数据给接收⽅，要考虑接收⽅处理能⼒。
如果⼀直⽆脑的发数据给对⽅，但对⽅处理不过来，那么就会导致触发重传机制，从⽽导致⽹络流重的⽆端的浪费。

为了解决这种现象发⽣，TCP 提供⼀种机制可以让「发送⽅」根据「接收⽅」的实际接收能⼒控制发送的数据量，
这就是所谓的流量控制。

1、假如发送方报文丢失，那么接收方回传的ack会一直不包含丢失字段，则发送方会在重传等待时间结束后对丢失报文段进行重传。接收方利用接受窗口大小这个参考，控制发送方的发送速率。

2、假如接收方有了新的可缓存空间，并将消息发送给发送方的途中，报文丢失，那么发送方一直以为接收方没有空间接收，而接收方也并不知道自己的报文丢失。这样就陷入死锁状态。为了打破死锁，发送方每发送一次报文都会启动一个持续计时器，当持续计时器超时的时候，发送零窗口探测报文。询问是否依旧是没有缓存空间。零窗口探测报文对于接收方没有空间要求，且也有超时重传机制。

拥塞控制

前⾯的流量控制是避免「发送⽅」的数据填满「接收⽅」的缓存，但是并不知道⽹络的中发⽣了什么。

而拥塞控制是当⽹络发送拥塞时，TCP 会⾃我牺牲，降低
发送的数据量。控制的⽬的就是避免「发送⽅」的数据填满整个⽹络。

拥塞控制主要是4个算法：

慢开始：从1开始倍数增长。
拥塞避免：如果当拥塞窗⼝ cwnd 「超过」慢启动⻔限 ssthresh就进入拥塞避免算法。一般ssthresh的大小是65535。进入拥塞避免算法后，每次线性增加1。如果网络发送拥塞，有丢包现象发生，就会触发重传机制，将ssthresh 设为 cwnd/2，cwnd窗口值设置为1，并执行慢开始算法。
快重传：发送方一旦收到3个连续的重复确认，立即重传相应报文段。TCP认为在还能收到3个连续重复确认的情况下，说明大部分没丢，只是丢了一小部分。于是将cwnd拥塞窗口设置为原来的一半，将ssthresh设置为cwnd，然后进入快速恢复算法。
快恢复：拥塞窗口 cwnd = ssthresh + 3（3的意思是确认有3个数据包收到了），重传丢失的数据包，如果再收到重复的ACK，那么cwnd增加1.

UDP协议

应用层

HTTP

HTTP 是⼀个在计算机世界⾥专⻔在「两点」之间「传输」⽂字、图⽚、⾳频、视频等「超⽂本」数据的「约定和
规范」

session，cookie，token的应用与区别

由于http是无状态的会话，所以我们需要一个东西来记录区分不同用户的信息，主要有下边三种方式

session ：在服务端记录，每一个会话会产生一个session。当某用户打开某个web应用时，便与web服务器产生一次session。服务器使用session将用户的信息临时保存在服务器上，用户离开网站后，session会自动销毁，这样服务器就会根据每个人的sessionid不同，从而区别开不同用户的请求，返回给用户不同的请求结果。
- 缺点：在目前服务器都使用分布式部署的情况下，万一上一个请求和下一个请求，响应的是不同的服务器，那么后边没用存储session的机器就会任务该请求没用登录。如果使用session复制，将会增加很多开销，不是理想方案。
cookie
cookie是服务端保存在客户端的临时的少量的数据，cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求同一网站时，会把该cookie发送给服务器。cookie是存在客户端的，所以浏览器加入了一些限制，以确保cookie不会被恶意使用，同时不会占用太多磁盘空间，所以每个域的cookie的数量是有限的。
- 缺点：cookie这种方式很容易被恶意攻击者入侵，黑客会伪造session来登录访问。这个时候就需要一种加密的方法，来验证这个cookie的id是否由我自己的服务器之前生成，而非伪造或者篡改的。
token
token是服务端生成的一串字符，当作客户端进行请求的一个令牌，当第一次登录后，服务器为客户端生成一个token（令牌），以后客户端只需要带上这个token来请求，就会被视为登录状态。
区别：
- session存在服务器端，cookie存在客户端，token是服务器分配给客户端，客户带token访问视为登录。

HTTP常见字段有哪些？

host字段：客户端发送请求时，用来指定服务器的域名，有了host字段就可以将请求发往同一台服务器上的不同网站
content-length 字段：服务器在返回数据时会有content-length字段，表示本次回应的数据长度
connection字段：connection字段最常用于客户端要求服务器使用TCP持久连接，以便其他请求复用。
HTTP/1.1 版本的默认连接都是持久连接，但为了兼容⽼版本的 HTTP，需要指定 Connection ⾸部字段的值为Keep-Alive

Connection: keep-alive

content-type字段该字段用于服务器回应时，告诉客户端本次数据是什么格式

Content-Type: text/html; charset=utf-8

客户端请求的时候，可以使⽤ Accept 字段声明⾃⼰可以接受哪些数据格式。

Content-Encoding 字段
Content-Encoding 字段说明数据的压缩⽅法。表示服务器返回的数据使⽤了什么压缩格式
客户端在请求时，⽤ Accept-Encoding 字段说明⾃⼰可以接受哪些压缩⽅法。

HTTP状态码

1xx 类状态码属于提示信息，是协议处理中的⼀种中间状态，实际⽤到的⽐较少

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态

「200 OK」是最常⻅的成功状态码，表示⼀切正常。如果是⾮ HEAD 请求，服务器返回的响应头都会有 body数据
「204 No Content」也是常⻅的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
「206 Partial Content」是应⽤于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，⽽是其中的⼀部分，也是服务器处理成功的状态

3xx 类状态码表示客户端请求的资源发送了变动，需要客户端⽤新的 URL新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改⽤新的 URL 再次访问。
「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要⽤另⼀个 URL 来访问。
301 和 302 都会在响应头⾥使⽤字段 Location ，指明后续要跳转的 URL，浏览器会⾃动重定向新的 URL。
「304 Not Modified」不具有跳转的含义，表示资源未修改，᯿定向已存在的缓冲⽂件，也称缓存重定向，⽤于缓存控制

4xx 类状态码表示客户端发送的报⽂有误，服务器⽆法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报⽂有错误，但只是个笼统的错误。
「403 Forbidden」表示服务器禁⽌访问资源，并不是客户端的请求出错。
「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以⽆法提供给客户端。

5xx 类状态码表示客户端请求报⽂正确，但是服务器处理时内部发⽣了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通⽤的错误码，服务器发⽣了什么错误，我们并不知道。
「501 Not Implemented」表示客户端请求的功能还不⽀持，类似“即将开业，敬请期待”的意思。
「502 Bad Gateway」通常是服务器作为⽹关或代理时返回的错误码，表示服务器⾃身⼯作正常，访问后端服务器发⽣了错误。
「503 Service Unavailable」表示服务器当前很忙，暂时⽆法响应服务器，类似“⽹络服务正忙，请稍后重试”的意思。

GET和POST的区别？

Get （获取）⽅法的含义是请求从服务器获取资源，这个资源可以是静态的⽂本、⻚⾯、图⽚视频等。

POST（投递）⽅法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报⽂的 body ⾥。

HTTP和HTTPS的区别？

HTTP是超文本传输协议，信息是明文传输，存在安全风险问题，HTTPS则解决了HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
HTTP连接建立简单，TCP三次握手之后便可以进行HTTP的报文传输，而HTTPS在TCP三次握手之后，还需要进行SSL/TSL握手，才可以进入加密报文传输。
HTTP的端口号是80，HTTPS的端口号是443
HTTPS协议需要向CA(证书权威机构)申请数字证书，来保证服务器身份是可信的。

HTTPS解决了HTTP哪些问题，是怎么解决的？

HTTP由于是明文传输，安全上存在窃听、篡改和冒充的风险。
HTTPS在HTTP与TCP层之间加入了SSL/TSL协议，通过对信息的混合加密，防止窃听；采用校验机制，使用摘要算法，为数据生成独一无二的指纹，用于校验数据的完整性，防止数据篡改；将服务器公钥放入到数字证书中，解决身份冒充的风险。

SLL/TLS协议基本流程

客户端向服务器索要并验证服务器的公钥
双方协商生成会话秘钥
双方采用会话秘钥进行加密通信

前两步也就是SSL/TSL的建立过程，也就是握手阶段。

HTTP/1.1、HTTP/2、HTTP/3演变

HTTP/1.1 相⽐ HTTP/1.0 性能上的改进：
使⽤ TCP ⻓连接的⽅式改善了 HTTP/1.0 短连接造成的性能开销。
⽀持管道（pipeline）⽹络传输，只要第⼀个请求发出去了，不必等其回来，就可以发第⼆个请求出去，可以
减少整体的响应时间

但 HTTP/1.1 还是有性能瓶颈：
请求 / 响应头部（Header）未经压缩就发送，⾸部信息越多延迟越⼤。只能压缩 Body 的部分；
发送冗⻓的⾸部。每次互相发送相同的⾸部造成的浪费较多；
服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端⼀直请求不到数据，也就是队头阻塞；
没有请求优先级控制；
请求只能从客户端开始，服务器只能被动响应。

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
其他改进：

头部压缩：HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是⼀样的或是相似的，那么，协议会帮你消除重
复的部分。
这就是所谓的 HPACK 算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引
号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。
二进制格式
HTTP/2 不再像 HTTP/1.1 ⾥的纯⽂本形式的报⽂，⽽是全⾯采⽤了⼆进制格式，头信息和数据体都是⼆进制，并
且统称为帧（frame）：头信息帧和数据帧。
数据流
HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。因此，必须要对数据
包做标记，指出它属于哪个回应。
每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独⼀⽆⼆的编号，其中规
定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数
客户端还可以指定数据流的优先级。优先级⾼的请求，服务器就先响应该请求。
多路复用
HTTP/2 是可以在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应。
移除了 HTTP/1.1 中的串⾏请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，⼤幅度提⾼
了连接的利⽤率。
举例来说，在⼀个 TCP 连接⾥，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程⾮常耗时，于是就
回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。
服务器推送
HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动向客户端发
送消息。
举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS ⽂件等静态资源主动发给客户端，减
少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求
的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的重传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等
待这个丢了的包被重传回来

这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

UDP 发⽣是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞和 HTTP/2 的⼀个丢包全部᯿传问
题。
⼤家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议可以实现类似 TCP 的可靠性传输。

QUIC 有⾃⼰的⼀套机制可以保证传输的可靠性的。当某个流发⽣丢包时，只会阻塞这个流，其他流不会受到
影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack 。
HTTPS 要建⽴⼀个连接，要花费 6 次交互，先是建⽴三次握⼿，然后是 TLS/1.3 的三次握⼿。QUIC 直接把
以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。

Web Socket协议

webSoket 出现是因为普通的http请求，只是客户端发送请求，然后服务器接收，想要获取服务器端的消息只能通过Ajax请求，但h5之后出现的webSoket，打破了这一僵局~~~实现了客户端和服务器端全双工通信。

特点：建立连接之后一直保持连接状态。
连接建立过程：
1、客户端发送GET 请求， upgrade
2、服务器给客户端 switching protocol
3、就进行了webSocket的通信了

域名解析协议（DNS，Domain Name System）

客户端⾸先会发出⼀个 DNS 请求，问 www.server.com 的 IP 是啥，并发给本地 DNS 服务器（也就是客户端
的 TCP/IP 设置中填写的 DNS 服务器地址）。
本地域名服务器收到客户端的请求后，如果缓存⾥的表格能找到 www.server.com，则它直接返回 IP 地址。如
果没有，本地 DNS 会去问它的根域名服务器：“⽼⼤，能告诉我 www.server.com 的 IP 地址吗？” 根域名服
务器是最⾼层次的，它不直接⽤于域名解析，但能指明⼀条道路。
根 DNS 收到来⾃本地 DNS 的请求后，发现后置是 .com，说：“www.server.com 这个域名归 .com 区域管
理”，我给你 .com 顶级域名服务器地址给你，你去问问它吧。”
本地 DNS 收到顶级域名服务器的地址后，发起请求问“⽼⼆，你能告诉我 www.server.com 的 IP 地址吗？”
顶级域名服务器说：“我给你负责 www.server.com 区域的权威 DNS 服务器的地址，你去问它应该能问到”。
本地 DNS 于是转向问权威 DNS 服务器：“⽼三，www.server.com对应的IP是啥呀？” server.com 的权威 DNS
服务器，它是域名解析结果的原出处。为啥叫权威呢？就是我的域名我做主。
权威 DNS 服务器查询后将对应的 IP 地址 X.X.X.X 告诉本地 DNS。
本地 DNS 再将 IP 地址返回客户端，客户端和⽬标建⽴连接。

为什么域名解析用UDP协议？

因为UDP快啊！UDP的DNS协议只要一个请求、一个应答就好了。
而使用基于TCP的DNS协议要三次握手、发送数据以及应答、四次挥手，但是UDP协议传输内容不能超过512字节。
不过客户端向DNS服务器查询域名，一般返回的内容都不超过512字节，用UDP传输即可。

动态主机配置协议（DHCP，Dynamic Host Configuration Protocol）

Linux网络编程

TCP的socket编程

服务端和客户端初始化 socket ，得到⽂件描述符；
服务端调⽤ bind ，将绑定在 IP 地址和端⼝;
服务端调⽤ listen ，进⾏监听；
服务端调⽤ accept ，等待客户端连接；
客户端调⽤ connect ，向服务器端的地址和端⼝发起连接请求；
服务端 accept 返回⽤于传输的 socket 的⽂件描述符；
客户端调⽤ write 写⼊数据；服务端调⽤ read 读取数据；
客户端断开连接时，会调⽤ close ，那么服务端 read 读取数据的时候，就会读取到了 EOF ，待处理完数据后，服务端调⽤ close ，表示连接关闭。

需要注意的是：监听的 socket 和真正⽤来传送数据的 socket，是「两个」 socket，⼀个叫作监听 socket，⼀个叫作已完成连接 socket。

成功连接建⽴之后，双⽅开始通过 read 和 write 函数来读写数据，就像往⼀个⽂件流⾥⾯写东⻄⼀样。

Linux内核中会维护两个队列：

半连接队列（SYN 队列）：接收到⼀个 SYN 建⽴连接请求，处于 SYN_RCVD 状态；
全连接队列（Accpet 队列）：已完成 TCP 三次握⼿过程，处于 ESTABLISHED 状态；

八股总结（二）计算机网络与网络编程相关推荐

计算机网络（二）Linux网络编程
layout: post title: 计算机网络(二)Linux网络编程 description: 计算机网络(二)Linux网络编程 tag: 计算机网络文章目录资源共享 Linux高性能服务 ...
学习笔记（二十）—— 网络编程
文章目录一.网络通信概述 1.1.什么是网络 1.2.使用网络的目的二.TCP/IP简介 2.1.什么是协议 2.2.计算机网络沟通三.端口和端口号 3.1.什么是端口 3.2.端口号 3.3. ...
南邮Android实验报告二：安卓网络编程
实验二安卓网络编程一.目的要求 1.理解安卓应用开发中调用web服务的过程和方法. 2.学习在应用开发中使用第三方开发包的过程和方法. 3.掌握json数据的解析方法. 二.实验环境 1.硬件配置 ...
Java Web 实战 15 - 计算机网络之网络编程套接字
文章目录一 . 网络编程中的基本概念 1.1 网络编程 1.2 客户端(client) / 服务器(server) 1.3 请求(request) / 响应(response) 1.4 客户端和服务 ...
简谈计算机网络与网络编程
网络概念 : 首先.网络可以使不同物理位置上的计算机达到资源共享和通信的目的,在java中提供了专门的网络开发包----java.net来使用,当然也有随着时代技术的进步革新,会出现更多的API. 此 ...
Java从接触到放弃（二十一）--网络编程
Day Twenty-One 网络编程网络编程中有两个主要的问题如何准确的定位到网络上的一台或者多台主机找到主机之后如何进行通信网络编程中的要素 IP和端口号网络通信协议 udp,tcp I ...
计算机网络与网络编程
目录知识点网络协议模型网络字节序 (很绕的概念) 什么是TCP 交换机与路由器 TCP三次握手 TCP四次挥手 TCP与UDP区别概念适用范围 TCP可靠性保证 TCP三次握手时产生的队列 ...
【计算机网络】网络编程前置-udptcp/ip
一.计算机网络基础知识 1.什么是计算机网络 ***** 把分布在不同地理位置的计算机与专门的网络设备用通信线路互相连成一个规模大.功能强的系统,从而使众多计算机可以方便地互相传递信息.共享软件.硬件 ...
Python学习日记(二十九) 网络编程
早期的计算机通信需要有一个中间件,A要给B传东西,A必须要把信息传给中间件,B再把从中间件中拿到信息由于不同机器之间需要通信就产生了网络软件开发的架构 1.C/S架构服务器-客户机,即Clien ...

八股总结（二）计算机网络与网络编程