常见问题带答案

还未整理，较杂乱。

#TODO

——2021/6/14

ipv4和ipv6的差别

IP是因特网的核心协议。现在使用的IP（即IPv4）是在20世纪70年代末期设计的。因特网经过几十年的飞速发展，到2011年2月，IPv4的地址已经耗尽，ISP已经不能再申请到新的IP地址块了。为此，解决IP地址耗尽的根本措施就是采用具有更大地址空间的新版本的IP，即IPv6。

✅osi和tcp/ip网络模型，路由器和交换机位于哪一层

https://blog.csdn.net/kavensu/article/details/8020400

img

• 路由器：应该是网络层

  • 网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组或包(packet)进行传送。

  • 因特网主要的网络层协议是无连接的网际协议IP (InternetProtocol)和许多种路由选择协议，因此因特网的网络层也叫做网际层或IP层。在本书中，网络层、网际层和IP层都是同义语。

  • 综上，路由选择协议是在路由器中使用的，所以路由器应该是位于网络层的。

• 交换机：应该是数据链路层

  • 1990年问世的交换式集线器(switching hub)，可明显地提高以太网的性能。交换式集线器常称为以太网交换机(switch)或第二层交换机，表明这种交换机工作在数据链路层。“交换机”并无准确的定义和明确的概念，而现在的很多交换机已混杂了网桥和路由器的功能。

✅计算机网络有哪几层？分别对应什么协议

这个要看不同的体系结构，已知是有三个网络体系结构：

• OSI的七层协议体系结构。理论也较完整，但它既复杂又不实用。

• TCP/IP四层体系结构。它现在已经得到了非常广泛的应用。TCP/IP是一个四层的体系结构。不过从实质上讲，TCP/IP只有最上面的三层，因为最下面的网络接口层基本上和一般的通信链路在功能上没有多大差别，对于计算机网络来说，这一层并没有什么特别新的具体内容。

• 五层协议体系结构。在学习计算机网络的原理时往往采取折中的办法，即综合OSI和TCP/IP的优点，采用一种只有五层协议的体系结构，这样既简洁又能将概念阐述清楚。

对应的协议如下图：

img

这里可以总结一下这些协议对应的中文名称：

• HTTP

  • HyperText Transfer Protocol 超文本传输协议

• TFTP 简单文件传送协议（为什么不叫Simple File呢！）

  • TCP/IP协议族中还有一个简单文件传送协议TFTP (Trivial File Transfer Protocol)，它是一个很小且易于实现的文件传送协议。

• FTP 文件传送协议

  • 文件传送协议FTP (File Transfer Protocol) [RFC 959]是因特网上使用得最广泛的文件传送协议。FTP提供交互式的访问，允许客户指明文件的类型与格式（如指明是否使用ASCII码），并允许文件具有存取权限（如访问文件的用户必须经过授权，并输入有效的口令）。FTP屏蔽了各计算机系统的细节，因而适合于在异构网络中任意计算机之间传送文件。RFC959很早就成为了因特网的正式标准。

• NFS

  • 属于文件共享协议的有网络文件系统NFS(Network File System) [COME06]。网络文件系统NFS最初是在UNIX操作系统环境下实现文件和目录的共享。NFS可使本地计算机共享远程的资源，就像这些资源在本地一样。由于NFS原先是美国SUN公司在TCP/IP网络上创建的，因此目前NFS主要应用在TCP/IP网络上。然而现在NFS也可在OS/2,MS-Windows, NetWare等操作系统上运行。NFS还没有成为因特网的正式标准，现在的版本4（NFSv4）是2000年底发表的[RFC 3010]，目前还只是建议标准。限于篇幅，本书不讨论NFS的详细工作过程。

• WAIS

  • 教材都搜不到，不用管。

• SMTP 简单邮件传送协议

  • 1982年ARPANET的电子邮件标准问世：简单邮件传送协议SMTP (Simple Mail Transfer Protocol) [RFC 821]和因特网文本报文格式[RFC 822]。电子邮件很快就成为最受广大网民欢迎的因特网应用。

• Telnet 远程终端协议

  • TELNET是一个简单的远程终端协议[RFC 854]，它也是因特网的正式标准。用户用TELNET就可在其所在地通过TCP连接注册（即登录）到远地的另一个主机上（使用主机名或IP地址）。TELNET能将用户的击键传到远地主机，同时也能将远地主机的输出通过TCP连接返回到用户屏幕。这种服务是透明的，因为用户感觉到好像键盘和显示器是直接连在远地主机上。因此，TELNET又称为终端仿真协议。

• SNMP 简单网络管理协议

  • 简单网络管理协议SNMP (Simple Network ManagementProtocol)中的管理程序和代理程序按客户-服务器方式工作。管理程序运行SNMP客户程序，而代理程序运行SNMP服务器程序。

• DNS 域名系统

  • 域名系统DNS (Domain Name System)是因特网使用的命名系统，用来把便于人们使用的机器名字转换为IP地址。域名系统其实就是名字系统。为什么不叫“名字”而叫“域名”呢？这是因为在这种因特网的命名系统中使用了许多的“域”(domain)，因此就出现了“域名”这个名词。

• TCP

  • 传输控制协议TCP (Transmission Control Protocol)——提供面向连接的、可靠的数据传输服务，其数据传输的单位是报文段(segment)。

• UDP

  • 用户数据报协议 UDP (User Datagram Protocol)——提供无连接的、尽最大努力(best-effort)的数据传输服务（不保证数据传输的可靠性），其数据传输的单位是用户数据报。

• IP 网际协议IP

  • Internet Protocol 互联网协议

  • 网际协议IP是TCP/IP体系中两个最主要的协议之一，也是最重要的因特网标准协议之一。与IP协议配套使用的还有三个协议：ARP，ICMP，IGMP。本来还有一个协议叫做逆地址解析协议RARP (ReverseAddress Resolution Protocol)，是和ARP协议配合使用的。但现在已被淘汰不使用了。

  • IP是Internet Protocol（网际互连协议）的缩写，是TCP/IP体系中的网络层协议。设计IP的目的是提高网络的可扩展性：一是解决互联网问题，实现大规模、异构网络的互联互通；二是分割顶层网络应用和底层网络技术之间的耦合关系，以利于两者的独立发展。根据端到端的设计原则，IP只为主机提供一种无连接、不可靠的、尽力而为的数据包传输服务。

• ICMP

  • 网际控制报文协议ICMP (Internet Control MessageProtocol)

• IGMP

  • 网际组管理协议IGMP (Internet Group ManagementProtocol)

• ARP

  • 地址解析协议ARP (Address Resolution Protocol)

• RARP

  • 本来还有一个协议叫做逆地址解析协议RARP (ReverseAddress Resolution Protocol)，是和ARP协议配合使用的。但现在已被淘汰不使用了。

  • https://www.codenong.com/p11923567/

  • RARP已经被淘汰了，原因有两个：首先，RARP利用了数据链路层的广播服务，这也就表示每个网络上都必须存在一台RARP服务器。第二，RARP只能提供计算机的IP地址，但如今的计算机需要前面提到的所有四种信息——（每个连接到TCP/IP互联网的计算机都必须知道自己的IP地址、一个路由器的IP地址、一个名字服务器的IP地址以及自己的子网掩码这四种信息）

• AKP

  • 教材都搜不到，不用管。

• UUCP

  • 同上

• SLIP

  • 同上

• PPP 点对点协议PPP (Point-to-Point Protocol)

  • 在通信线路质量较差的年代，在数据链路层使用可靠传输协议曾经是一种好办法。因此，能实现可靠传输的高级数据链路控制HDLC (High-level Data Link Control)就成为当时比较流行的数据链路层协议。但现在HDLC已很少使用了。对于点对点的链路，简单得多的点对点协议PPP (Point-to-PointProtocol)则是目前使用得最广泛的数据链路层协议。

  • 我们知道，因特网用户通常都要连接到某个ISP才能接入到因特网。PPP协议就是用户计算机和ISP进行通信时所使用的数据链路层协议。

✅TCP连接的三次握手，四次挥手

3次握手、4次挥手、为什么不4次、5次

三次握手，没有第三次会有什么影响

三次握手，四次挥手

TCP三次握手原理及细节，谈及为什么不能两次握手的原因

TCP挥手 第三次不挥手会怎么样

以上都是一个问题啦，搞清楚就可以回答全部的问题噜。

三次握手

A 为客户端，B 为服务器端。checksum、ack、seq：sequence number

• 首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。

• A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。（SYN同步序列编号

• B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。

• A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。

• B 收到 A 的确认后，连接建立。

为什么三次握手？不三次握手会怎么样？

三次握手的原因：

第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。

如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

教材原话：

为什么A还要发送一次确认呢？这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

所谓“已失效的连接请求报文段”是这样产生的。考虑一种正常情况。A发出连接请求，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。

现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。

假定不采用三次握手，那么只要B发出确认，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

四次挥手

以下描述不讨论序号和确认号，因为序号和确认号的规则比较简单。并且不讨论 ACK，因为 ACK 在连接建立之后都为 1。

• A 发送连接释放报文，FIN=1。

• B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。

• 当 B 不再需要连接时，发送连接释放报文，FIN=1。

• A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。

• B 收到 A 的确认后释放连接。

❓四次挥手的原因 ：

• 客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

• 👉这段在说连接问题：因为当 Server 端收到 Client 端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。 其中 ACK 报文是用来应答的，SYN 报文是用来同步的。

• 👉开始说断开连接了：但是关闭连接时，当 Server 端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个 ACK 报文，告诉 Client端，"你发的 FIN 报文我收到了"。只有等到我 Server 端所有的报文都发送完了，我才能发送 FIN 报文，因此不能一起发送。故需要四步握手。

❓客户端为什么进入 TIME_WAIT 状态 ：客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

• 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。

• 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

❓TCP服务端能否无限等待 #TODO

：我觉得应该不能吧，不然不就无限浪费资源了吗。

❓在TCP断开连接的四次挥手中，客户端发送完最后一个ACK后会进入什么状态【time_wait后进入CLOSED状态】

：客户端接收到服务器端的 FIN 报文后进入TIME_WAIT状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。

❓TCP连接和释放中的状态有哪些，以及如果日志中出现某些状态码过多如何处理。#TODO

连接和释放中的状态：https://blog.csdn.net/qq_39387475/article/details/78154321

感觉这里是考察TCP有限状态机

但是感觉结合下面的握手挥手图一起理解会更清楚一些：

✅TCP属于哪一层，TCP与UDP协议区别

传输层

区别：

• 用户数据报协议 UDP（User Datagram Protocol）是无连接（发送即结束）的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。

• 传输控制协议 TCP（Transmission Control Protocol）是面向连接的，提供可靠交付，有流量控制，拥塞控制，提供全双工通信，面向字节流（把应用层传下来的报文看成字节流，把字节流组织成大小不等的数据块），每一条 TCP 连接只能是点对点的（一对一）。

UDP 首部格式

首部字段只有 8 个字节，包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。

TCP 首部格式

✅滑动窗口的实现机制以及如何作用流量控制

滑动窗口实现机制

窗口是缓存的一部分，用来暂时存放字节流。

发送方和接收方各有一个窗口：

• 接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小

• 发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。

如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

• 第一眼我还没看明白，31到34不是连续的，连续的话应该是31 32，所以这里只需要对31进行确认。

IP、TCP传输的都是什么数据？

• IP是网络层协议

• TCP是传输层协议！

• 传输层在网络层上面，即TCP运行在IP之上。TCP基于IP！

网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组或包(packet)进行传送。在TCP/IP体系中，由于网络层使用IP协议，因此分组也叫作 IP数据报，或简称为数据报(datagram)。本书把“分组”和“数据报”作为同义词使用。

• 请注意：不要将运输层的“用户数据报UDP”和网络层的“IP数据报”弄混。此外，无论在哪一层传送的数据单元，都可笼统地用“分组”来表示。

运输层的任务就是负责向两个主机中进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。所谓通用，是指并不针对某个特定网络应用，而是多种应用可以使用同一个运输层服务。由于一台主机可同时运行多个进程，因此运输层有复用和分用的功能。复用就是多个应用层进程可同时使用下面运输层的服务，分用与复用相反，是运输层把收到的信息分别交付上面应用层中的相应进程。

✅TCP为什么是可靠的 // TCP的可靠性

滑动窗口，超时重传，选择确认。 //还有拥塞（se）控制

保证了数据的准确性。

这个实际上就是回答TCP的可靠性呀。

📒教材

我们知道，TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠。

理想的传输条件有以下两个特点：

(1) 传输信道不产生差错。

(2) 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

在这样的理想传输条件下，不需要采取任何措施就能够实现可靠传输。然而实际的网络都不具备以上两个理想条件。但我们可以使用一些可靠传输协议，当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉发送方适当降低发送数据的速度。这样一来，本来是不可靠的传输信道就能够实现可靠传输了。下面从最简单的停止等待协议讲起[插图]。 -- 教材后面是讲可靠传输原理 可以不看了

我们首先介绍以字节为单位的滑动窗口。为了讲述可靠传输原理的方便，我们假定数据传输只在一个方向进行，即A发送数据，B给出确认。//面试的时候也可以假定

• 以字节为单位的滑动窗口

• 超时重传时间的选择

  • TCP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP最复杂的问题之一。

  • TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。

• 选择确认SACK

  • 那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的。选择确认就是一种可行的处理方法。

  • 我们用一个例子来说明选择确认(Selective ACK)的工作原理。TCP的接收方在接收对方发送过来的数据字节流的序号不连续，结果就形成了一些不连续的字节块（如图5-21所示）。可以看出，序号1～1000收到了，但序号1001～1500没有收到。接下来的字节流又收到了，可是又缺少了3001～3500。再后面从序号4501起又没有收到。也就是说，接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。

  • RFC 2018规定，如果要使用选择确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，那么原来首部中的“确认号字段”的用法仍然不变。只是以后在TCP报文段的首部中都增加了SACK选项，以便报告收到的不连续的字节块的边界。

  • 然而，SACK文档并没有指明发送方应当怎样响应SACK。因此大多数的实现还是重传所有未被确认的数据块。

✅TCP滑动窗口

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

✅TCP流量控制

流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

✅TCP拥塞控制

注意拥塞机制涉及的算法（慢开始，拥塞避免，快重传，快恢复）。

TCP的拥塞控制 慢开始

为什么需要快重传和快恢复，什么场景下使用？

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。

流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。

为了便于讨论，做如下假设：

• 接收方有足够大的接收缓存，因此不会发生流量控制；

• 虽然 TCP 的窗口基于字节，但是这里设窗口的大小单位为报文段。

1. 慢开始与拥塞避免

   发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 指数增大，因此之后发送方能够发送的报文段数量为：2、4、8 ...

   注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，这里初始 ssthresh = 24，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1，即 cwnd 加法增大（如①、③）。

   如果出现了超时（如②），则令 ssthresh = cwnd / 2 = 12, cwnd = 1 ，然后重新执行慢开始。

2. 快重传与快恢复

   在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

   在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2（如④），则 M3 丢失，立即重传 M3。

   在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh = 8（如⑤）。

   慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

✅如何在UDP上层保证UDP的可靠性传输？

UDP如何实现可靠传输。

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照 tcp 可靠性传输的方式。

如不考虑拥塞处理，可靠 UDP 的简单设计如下：

1、添加 seq/ack 机制，确保数据发送到对端

2、添加发送和接收缓冲区，主要是用户超时重传。

3、添加超时重传机制。

具体过程即是：送端发送数据时，生成一个随机 seq=x，然后每一片按照数据大小分配 seq。

数据到达接收端后接收端放入缓存，并发送一个 ack=x 的包，表示对方已经收到了数据。

发送端收到了 ack 包后，删除缓冲区对应的数据。时间到后，定时任务检查是否需要重传数

据。

目前有如下开源程序利用 udp 实现了可靠的数据传输。分别为 RUDP、RTP、UDT:

1、RUDP（Reliable User Datagram Protocol）

RUDP 提供一组数据服务质量增强机制，如拥塞控制的改进、重发机制及淡化服务器算法等。2、RTP（Real Time Protocol）

RTP 为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视

频音频或模拟数据。

3、UDT（UDP-based Data Transfer Protocol）

UDT 的主要目的是支持高速广域网上的海量数据传输。

UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。

传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

关键在于两点，从应用层角度考虑：

1 提供超时重传，能避免数据报丢失。

2 提供确认序列号，可以对数据报进行确认和排序。

客户端：首先在UDP数据报定义一个首部，首部包含确认序列号和时间戳，时间戳是用来计算RTT(数据报传输的往返时间)，从何计算出合适的RTO(重传的超时时间)。然后以等-停的方式发送数据报，即收到对端的确认之后才发送下一个的数据报。当时间超时，本端重传数据报，同时RTO扩大为原来的两倍，重新开始计时。

服务端：接受到一个数据报之后取下该数据报首部的时间戳和确认序列号，并添加本端的确认数据报首部之后发送给对端。根据此序列号对已收到的数据报进行排序并丢弃重复的数据报。

✅即时视频用什么协议，UDP主要有哪些应用？

UDP应用场景：效率要求相对高、要求网络通讯速度能尽量快，但是对准确性要求相对低且对网络通讯质量要求不高的场景。例如：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

✅网络较差用什么协议

UDP应用场景：效率要求相对高、要求网络通讯速度能尽量快，但是对准确性要求相对低且对网络通讯质量要求不高的场景。

由此应该是用UDP协议。

✅HTTP的八种方法，有没有用过 // 请求方法

其实不止八种，有九种，其中包括2种HTTP1.0种就定义好的三种，剩下六种是HTTP1.1新增的。然后简单介绍两句就好了。

GET PUT HEAD POST DELETE CONNECT OPTIONS TRACE PATCH

成对成对的记忆会比较好记

• GET-HEAD-POST

• PUT-PATCH

• DELETE-CONNECT-TRACE

• OPTIONS

菜鸟教程里有：https://www.runoob.com/http/http-methods.html

不要听到方法就懵逼了，这个就是在问HTTP的请求方法有哪些？能说出多少应该都行的。

根据 HTTP 标准，HTTP 请求可以使用多种请求方法。

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。

HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

搞清楚基础只有三个GET POST HEAD

序号	方法	描述
1	GET	请求指定的页面信息，并返回实体主体。
2	HEAD	类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
3	POST	向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
4	PUT	从客户端向服务器传送的数据取代指定的文档的内容。
5	DELETE	请求服务器删除指定的页面。
6	CONNECT	HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
7	OPTIONS	允许客户端查看服务器的性能。
8	TRACE	回显服务器收到的请求，主要用于测试或诊断。
9	PATCH	是对 PUT 方法的补充，用来对已知资源进行局部更新 。//本身就有打补丁的意思

✅HTTP是用什么实现的 #TODO

// http在应用层，那肯定是基于传输层来实现的？基于传输层的TCP

https://www.runoob.com/http/http-intro.html

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

这个是不是可以转换成什么问题？暂时搁置。

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。设计 HTTP 最初的目的是为了提供一种发布和接收 HTML 页面的方法。HTTP 协议是以明文方式发送信息的，如果黑客截取了 Web 浏览器和服务器之间的传输报文，就可以直接获得其中的信息。

① 客户端的浏览器首先要通过 TCP 与服务器建立连接，一般 TCP 连接的端口号是80。 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是 MIME 信息包括请求修饰符、客户机信息和许可内容。

② 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是 MIME 信息包括服务器信息、实体信息和可能的内容。

✅HTTP如何实现断点续传的。

如何实现断点续传

【计网】HTTP断点重传

HTTP1.1 协议（RFC2616）开始支持获取文件的部分内容，这为并行下载以及断点续传提供了技术支持。

它通过在 Header 里两个参数实现的。

• 客户端发请求时对应的是 Range

• 服务器端响应时对应的是 Content-Range。

✅HTTP和HTTPS区别

HTTP和HTTPS区别，在哪层

http和https区别，

http和https的区别

HTTPS介绍

http，https，区别

HTTP和HTTPS原理，区别，各自的优势

⬆️以上问题问的都是http和https的区别

【计网】http和https的区别

主要讲一下CA的流程就差不多可以了，我发现基本上我讲完，面试官都不会再问啦。

1、http是超文本传输协议，其中的信息是明文传输的。https是http协议再加上SSL（安全套接字层），具有安全性。

2、http不验证通信方的身份，通信方的身份有可能遭遇伪装；https需要到CA （证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http无法证明报文的完整性，报文有可能遭篡改。

5、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

6、HTTPS连接缓存不如HTTP高效，流量成本高。

7、HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。

8、根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。

9、HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。

HTTPS 解决了 HTTP 的哪些问题？

HTTP 由于是明文传输，所以安全上存在以下三个风险：

l 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。

l 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。

l 冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

l 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。

l 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。

l 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

可见，只要自身不做「恶」，SSL/TLS 协议是能保证通信是安全的。

✅👮‍♀️CA证书怎么生成，怎么保证安全，加密过程，对称加密怎么保证安全？

检验CA证书合法性是干啥的？

CA - Certification Authority 认证中心

加密密钥 - Public Key - 公钥

解密密钥 - Secret Key - 私钥 // 有误

每个通信方均需要两个密钥，即公钥和私钥，这两把密钥可以互为加解密。

在公钥密码体制中，加密密钥PK（public key，即公钥）是向公众公开的，而解密密钥SK（secret key，即私钥或秘钥）则是需要保密的。加密算法 E 和解密算法 D 也都是公开的。

在公钥密码体制中，如果每个用户都具有其他用户的公钥，就可实现安全通信。看来好像可以随意公布用户的公钥。

其实不然。设想用户A要欺骗用户B。A可以向B发送一份伪造是C发送的报文。A用自己的秘密密钥进行数字签名，并附上A自己的公钥，谎称这公钥是C的。B如何知道这个公钥不是C的呢？显然，这需要有一个值得信赖的机构来将公钥与其对应的实体（人或机器）进行绑定(binding)。这样的机构就叫作认证中心CA (Certification Authority)，它一般由政府出资建立。每个实体都有CA发来的证书(certificate)，里面有公钥及其拥有者的标识信息（人名或IP地址）。此证书被CA进行了数字签名。任何用户都可从可信的地方（如代表政府的报纸）获得认证中心CA的公钥，此公钥用来验证某个公钥是否为某个实体所拥有（通过向CA查询）。有的大公司（如Netscape），也提供认证中心服务。

• 采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问。

• 客户端内置CA的根证书(Root Certificate)（浏览器、操作系统里）， 里面包含CA公钥。客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。（这边写的客户端内置CA根证书待考究）

• 服务器去CA申请一个证书，CA用私钥对服务器公钥等信息进行加密生成了证书，然后发送给服务器。

• 为了确保根证书的绝对安全性，所以有了证书链，所以CA不会直接颁布证书，而是通过intermediates certificates给网站颁发证书

• 所谓证书链的验证，是想通过证书链追溯到可信赖的CA的根（ROOT）。换句话说，要验证签发用户实体证书的CA是否是权威可信的CA，如CFCA。证书链验证的要求是，路径中每个证书从最终实体到根证书都是有效的，并且每个证书都要正确地对应发行该证书的权威可信任性CA。

数字证书

如何保证公钥的可靠性呢？答案是数字证书，数字证书是身份认证机构

（Certificate Authority）颁发的，包含了以下信息：

• 证书颁发机构

• 证书颁发机构签名

• 证书绑定的服务器域名

• 证书版本、有效期

• 签名使用的加密算法（非对称算法，如 RSA）

• 公钥等

接收方收到消息后，先向 CA 验证证书的合法性，再进行签名校验。

注意：Apk 的证书通常是自签名的，也就是由开发者自己制作，没有向 CA 机构

申请。Android 在安装 Apk 时并没有校验证书本身的合法性，只是从证书中提取

公钥和加密算法，这也正是对第三方 Apk 重新签名后，还能够继续在没有安装

这个 Apk 的系统中继续安装的原因。

keystore 文件中包含了私钥、公钥和数字证书。根据编码不同，keystore 文件分

为很多种，Android 使用的是 Java 标准 keystore 格式 JKS(Java Key Storage)，

所以通过 Android Studio 导出的 keystore 文件是以.jks 结尾的。

✅客户端验证证书

CA证书机制的形象表述

• 客户端 sayHello

• 服务器返回证书

• 客户端检验证书的合法性，合法性检验包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的 "发行者的数字签名"，服务器证书上的域名是否和服务器的实际域名相匹配。

  • 验证证书内容有效性（过期时间， 域名是否相同等）

  • 验证证书的有效性 （是否被串改）， 通过查找"受信任的根证书颁发机构"列表，若找到对应证书的 公钥，就可以解密证书得到服务器公钥，再用服务器公钥解密数字签名得到摘要，然后再对信件本身使用哈希函数得到摘要，看两个摘要是否匹配，匹配的话数字签名通过，就可以使用服务器证书里面提供的公钥进行下一步通信。

✅数据传输的机密性

用非对称加密 对称加密的密钥，然后用对称加密密钥进行之后的加密通信

对称加密：对称密码体制中只有私钥。所以得让对方知道密钥，所以要保证密钥的安全。

非对称加密：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快。非对称密钥体制有公钥和私钥，①加解密：公钥加密，私钥解密；②签名：私钥加密数字摘要形成数字签名，公钥解密数字签名进行验证。

数字摘要：用哈希函数将要加密的明文”摘要“成一段长度固定的128比特的密文

数字签名：用私钥对数字摘要加密形成了签名

客户端和服务端在开始传输数据之前，会协商传输过程需要使用的加密算法。 客户端发送协商请求给服务端，其中包含自己支持的非对成加密的密钥交换算法 ( 一般是RSA)，数据签名摘要算法 ( 一般是SHA或者MD5) ，加密传输数据的对称加密算法 ( 一般是DES))，以及加密密钥的长度。 服务端接收到消息之后，选中安全性最高的算法，并将选中的算法发送给客户端，完成协商。客户端生成随机的字符串，通过协商好的非对称加密算法，使用服务端的公钥对该字符串进行加密，发送给服务端。 服务端接收到之后，使用自己的私钥解密得到该字符串。在随后的数据传输当中，使用这个字符串作为密钥进行对称加密。

✅HTTP1.0和HTTP1.1和HTTP2和HTTP3的区别

不管面试官怎么问，我回答的时候都可以从HTTP1.0开始递推到HTTP3.0

HTTP1和HTTP2的区别，HTTP2和HTTPS关系

👉HTTP1.1相比HTTP1.0的优化（挑几个点记住就行了）长连接、流水线、host字段、头部

1. HTTP1.1支持长连接和请求的流水线处理

   1. HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

   2. HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection。在同一个TCP的连接中可以传送多个HTTP请求和响应。多个请求和响应可以重叠，多个请求和响应可以同时进行。更加多的请求头和响应头(比如HTTP1.0没有host的字段)。

   3. HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。

2. 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。//就是流水线

   1. 请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。 HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。

3. HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

4. HTTP1.1增加host字段

   1. 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

   2. HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

5. 100（Continue）Status（节约带宽）

6. HTTP/1.1中引入了Chunked transfer-coding

7. HTTP/1.1在1.0的基础上加入了一些cache的新特性

👉HTTP1.1的性能瓶颈

l 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；

l 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；

l 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；

l 没有请求优先级控制；

l 请求只能从客户端开始，服务器只能被动响应。

👉HTTP2针对HTTP1.1的优化 // 压缩头部、二进制、数据流、多路复用

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

\1. 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。

\2. 二进制格式

HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧和数据帧。这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。

\3. 数据流

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。每个请求或回应的所有数据包，称为一个数据流（ Stream ）。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数。客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。

\4. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

\5. 服务器推送

HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动向客户端发送消息。举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是服务器推送（Server Push，也叫 Cache Push）。

👉HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？// 3就是tcp换成udp

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

HTTP/1.1 中的管道（ pipeline）传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了。

HTTP/2 多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

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

UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包全部重传问题。

UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议可以实现类似 TCP 的可靠性传输。

l QUIC【QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。】有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。

l TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了QPack 。

​ - 运输层安全TLS (Transport Layer Security)。

l HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。

所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题。所以 HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。

✅❓HTTP报文发送的全过程 // 访问URL的全过程

// 一次完整的HTTP请求过程

// 可以拿输入一个网址来举例

// 这个问题可以直接转换成「访问一个url的全过程」

可以吧我看人也是这么说的：

当我们输入 www.baidu.com 会发生什么？

0.浏览器输入 www.baidu.com ,HTTP 客户端发起一个请求,DNS 进行域名解析 URL 对应的 IP 地址。

1.解析出 IP 地址后，根据该 IP，建立服务器指定端口80 的TCP 连接。

2.HTTP 服务器端收到请求后，（如果连接成功的话？）发送一个状态行 HTTP/1.1 200 和响应消息

3.客户端与服务器断开 TCP 连接。

4.浏览器将响应报文信息显示出来。（html）

尽可能详细(答的乱七八糟的不过拼拼补补好像也差不多，建议自己多理一理从何说起，链路层/物理层不用说)

✅HTTP报文请求报头和HTTP报文响应报头 // 格式上的问题

HTTP的报文格式

http头

http报文首部的User-Agent字段

（1）HTTP 请求报文

HTTP 请求报文由请求行、请求头部、空行 和 请求包体 4 个部分组成，如下图所示：

// 图挂了之后找一下

下面对请求报文格式进行简单的分析：

请求行：请求行由方法字段、URL 字段 和HTTP 协议版本字段 3 个部分组成，他们之间使用空格隔开。常用的 HTTP 请求方法有 GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT;

● GET：当客户端要从服务器中读取某个资源时，使用GET 方法。GET 方法要求服务器将URL 定位的资源放在响应报文的数据部分，回送给客户端，即向服务器请求某个资源。使用GET 方法时，请求参数和对应的值附加在 URL 后面，利用一个问号(“?”)代表URL 的结尾与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。

● POST：当客户端给服务器提供信息较多时可以使用POST 方法，POST 方法向服务器提交数据，比如完成表单数据的提交，将数据提交给服务器处理。GET 一般用于获取/查询资源信息，POST 会附带用户数据，\一般用于更新资源信息**。POST 方法将请求参数封装在HTTP 请求数据中，以名称/值的形式出现，可以传输大量数据;

请求头部：请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

● User-Agent：产生请求的浏览器类型;

● Accept：客户端可识别的响应内容类型列表;星号 “ ” 用于按范围将类型分组，用 “ / ” 指示可接受全部类型，用“ type/ ”指示可接受 type 类型的所有子类型;

● Accept-Language：客户端可接受的自然语言;

● Accept-Encoding：客户端可接受的编码压缩格式;

● Accept-Charset：可接受的应答的字符集;

● Host：请求的主机名，允许多个域名同处一个IP 地址，即虚拟主机;

● connection：连接方式(close 或 keepalive);

● Cookie：存储于客户端扩展字段，向同一域名的服务端发送属于该域的cookie;

空行：最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头;

请求包体：请求包体不在 GET 方法中使用，而是在POST 方法中使用。POST 方法适用于需要客户填写表单的场合。与请求包体相关的最常使用的是包体类型 Content-Type 和包体长度 Content-Length;

请求头部

\（2）HTTP 响应报文

HTTP 响应报文由状态行、响应头部、空行 和 响应包体 4 个部分组成，如下图所示：

// 图挂了之后找一下

下面对响应报文格式进行简单的分析：

状态行：状态行由 HTTP 协议版本字段、状态码和状态码的描述文本 3 个部分组成，他们之间使用空格隔开;

● 状态码由三位数字组成，第一位数字表示响应的类型，常用的状态码有五大类如下所示：

1xx：表示服务器已接收了客户端请求，客户端可继续发送请求;

2xx：表示服务器已成功接收到请求并进行处理;

3xx：表示服务器要求客户端重定向;

4xx：表示客户端的请求有非法内容;

5xx：表示服务器未能正常处理客户端的请求而出现意外错误;

● 状态码描述文本有如下取值：

200 OK：表示客户端请求成功;

301 - 资源（网页等）被永久转移到其它URL;

302 Found-临时性重定向。该状态码表示请求的资源已被分配了新的URI，希望用户本次能使用新的URI访问。

304 Not Modified-该状态码表示客户端发送附带条件请求时，服务器端允许请求访问资源，但未满足条件的情况。

400 Bad Request：表示客户端请求有语法错误，不能被服务器所理解;

401 Unauthonzed：表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用;

403 Forbidden：表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因;

404 Not Found：请求的资源不存在，例如，输入了错误的URL;

500 Internal Server Error：表示服务器发生不可预期的错误，导致无法完成客户端的请求;

503 Service Unavailable：表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常;

响应头部：响应头可能包括：

Location：Location响应报头域用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源;

Server：Server 响应报头域包含了服务器用来处理请求的软件信息及其版本。它和 User-Agent 请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。

Vary：指示不可缓存的请求头列表;

Connection：连接方式;

对于请求来说：close(告诉WEB 服务器或者代理服务器，在完成本次请求的响应后，断开连接，不等待本次连接的后续请求了)。keepalive(告诉WEB服务器或者代理服务器，在完成本次请求的响应后，保持连接，等待本次连接的后续请求);

对于响应来说：close(连接已经关闭); keepalive(连接保持着，在等待本次连接的后续请求); Keep-Alive：如果浏览器请求保持连接，则该头部表明希望WEB 服务器保持连接多长时间(秒);例如：Keep-Alive：300;

WWW-Authenticate：WWW-Authenticate响应报头域必须被包含在401 (未授权的)响应消息中，这个报头域和前面讲到的Authorization 请求报头域是相关的，当客户端收到 401 响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了Authorization 报头域的请求;

空行：最后一个响应头部之后是一个空行，发送回车符和换行符，通知服务器以下不再有响应头部。

响应包体：服务器返回给客户端的文本信息;

响应头部

// 图挂了之后找一下

✅抓包工具的原理

Q：抓包工具用过吗，为什么抓包可以抓取https的所有数据(不会，说抓包抓到的都是加密后的数据，数据可能是没用的，面试官说可以抓到正确数据，问我，我随便说了下可能是通过截取正确证书，然后发送假证书给客户端，然后自己自己进行加密解密过程，最后得到明文)

Wireshark抓包分析——TCP/IP协议

https://blog.csdn.net/wangyiyungw/article/details/82178070

抓包工具原理与实践

https://juejin.cn/post/6844904053248360455

⬆️这个讲得很好

一句话阐述抓包工具的原理：抓包工具会在网络传输的某个层次或节点截获收发的数据

不同抓包工具的工作工作原理类似但实现方式不尽相同，如：

• charles本质是一个应用程序（如浏览器）的http代理

• chrome的network则是直接在浏览器应用程序内部实现

• wireshark则会直接在网卡，也就是链路层到物理层去抓取数据

抓包工具如何抓取明文的https数据

• charles作为一个客户端的代理，可以拿到服务端的证书（让代理可以取代客户端与服务器直接通信），然后动态生成一个证书给客户端（解决浏览器的证书校验），所以抓取客户端的https数据需要在客户端安装代理的CA证书

• wireshark则需要获取并导入ssl会话中生成的对称密钥来进行密文数据的解密

✅HTTP常用状态码

http协议的状态码 200、301、304、404、502 HTTP状态码解释

状态码200、404、500(都是最常见的)

http 3xx系列的状态码

200 – 请求成功

301 – 资源(网页等)被永久转移到其它URL

404 – 请求的资源(网页等)不存在

500 – 内部服务器错误

14种常见状态码

	类别	原因短语
1xx	Informational（信息性状态码）	接受的请求正在处理
2xx	Success（成功状态码）	请求正常处理完毕
3xx	Redirection（重定向）	需要进行附加操作以完成请求
4xx	Client error（客户端错误）	客户端请求出错，服务器无法处理请求
5xx	Server Error（服务器错误）	服务器处理请求出错

下面三种状态行在响应报文中是经常见到的。

// 图挂了- -

若请求的网页从http://www.ee.xyz.edu/index.html转移到了一个新的地址，则响应报文的状态行和一个首部行就是下面的形式：

// 图又挂了- -

HTTP和HTTPS的区别，HTTPS加密过程（https是如何安全的，用到了什么加密算法，怎么获取私钥），中间URL怎么变，HTTP的长连接和短连接，HTTP头部有哪些内容，http2.0和http1.0区别,

❓如果没有HTTP2.0，怎么解决短连接问题

// todo

✅HTTP长短连接

（1）定义：

长连接：在一个TCP连接上可以发送多个数据包，但是如果没有数据包发送时，也要双方发检测包以维持这个长连接；三次握手后连接，不断开连接，保持客户端和服务端通信，直到服务器超时自动断开连接，或者客户端主动断开连接。

短连接：当双方需要数据交互的时候，就建立一个TCP连接，本次交互完之后就断开这个连接；三次握手后建立连接，发送数据包并得到服务器返回的结果后，通过客户端和服务器的四次握手后断开连接。

l HTTP/1.0默认使用短连接，HTTP/1.1开始默认使用长连接；

l HTTP协议的长连接和短连接，实质就是TCP协议的长连接（keepalive）和短连接；

l TCP协议建立连接需要3次握手，断开连接需要4次握手，这个过程会消耗网络资源和时间；

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：Connection:keep-alive。

（2）优缺点

长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。短连接不需要服务器承担太大负担，只要存在的连接就是有用的连接，但如果客户端请求频繁，就会在TCP的建立连接和断开连接上浪费较大的资源和时间。

（3）什么时候用长连接，短连接？

短连接：适用于网页浏览等数据刷新频度较低的场景。一般而言像及京东，淘宝这些大型网站，随时都会有成千上万的用户请求，一般使用短连接，用户量太大，服务器扛不住那么多长连接；像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

长连接：适用于客户端和服务端通信频繁的场景，长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：聊天室，实时游戏等场景。即时通讯（QQ）般使用的都是长连接，但并不是永久连接（比如20分钟，半个小时），因为即时通讯是频繁的发送请求，使用长连接只需要建立一次连接，同时再根据业务设置保持时间，超过这个时间就会断开连接，一定程度上保证了服务器的压力不会过大。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

（4）Socket心跳包机制：

像心跳一样，每隔固定时间向服务器发送一个包，以此来告诉服务器，这个客户端还活着。

为了保持长连接，一般都是很小的包（节约流量）或者只有包头的空包。

心跳检测步骤：

1.客户端每隔一段时间间隔就发送一个探测包给服务器；

2.客户端发包时启动一个超时定时器；

3.服务端接收到探测包后会回应一个包；

4.如果客户端收到服务器的应答包，则说明服务器正常，删除超时定时器；如果没有收到则服务器异常。

✅HTTP缓存

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ

通过复用以前获取的资源，可以显著提高网站和应用程序的性能。Web 缓存减少了等待时间和网络流量，因此减少了显示资源表示形式所需的时间。通过使用 HTTP缓存，变得更加响应性。

缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。这样带来的好处有：缓解服务器端压力，提升性能(获取资源的耗时更短了)。

对于网站来说，缓存是达到高性能的重要组成部分。缓存需要合理配置，因为并不是所有资源都是永久不变的：重要的是对一个资源的缓存应截止到其下一次发生改变（即不能缓存过期的资源）。

字节面试问到了

https://www.cnblogs.com/chenqf/p/6386163.html

✅访问网页的流程

网页中输入一个网址会发生啥(DNS，http，tcp，ip。。。）

访问一个页面发生了什么

再浏览器中输入url回车后发生了什么

浏览器输入网址之后的具体操作

在浏览器中输入一个网站点击回车会发生什么

你在访问一个网站的时候，发生了什么，涉及到什么协议，讲传输层里的。

// 看到有人说回答这个问题可以8个步骤来答。这样确实好梳理一点。

1.DNS域名解析； 2.建立TCP连接； 3.发送HTTP请求； 4.服务器处理请求； 5.返回响应结果； 6.关闭TCP连接； 7.浏览器解析HTML； 8.浏览器布局渲染；

https://segmentfault.com/a/1190000012092552⭐️

📒笔记

比较简明扼要，方便记忆。

• DNS解析：浏览器查找域名的IP地址（DNS查找过程：浏览器/OS缓存，路由器缓存，DNS缓存）

• TCP连接

• HTTP连接：浏览器向web服务器发送一个HTTP请求（cookies会随着请求发送给服务器），服务器处理请求（请求、处理请求&它的参数、cookies、生成一个HTML响应）

• 服务器返回一个HTML响应

• 浏览器显示HTML

👉所用到的协议：（这个确实可以主动cue耶）（而且感觉是你不主动cue也会被问的东西）

DNS，获取域名对应的IP地址

TCP：与服务器建立TCP连接

IP：建立TCP连接时发送的数据在网络层使用IP协议

OSPF：IP数据包在路由器之间转发。路由器选择OSPF

• 这个协议的名字是开放最短路径优先OSPF (Open ShortestPath First)。它是为克服RIP的缺点在1989年开发出来的。OSPF的原理很简单，但实现起来却较复杂。“开放”表明OSPF协议不是受某一家厂商控制，而是公开发表的。“最短路径优先”是因为使用了Dijkstra提出的最短路径算法SPF（见光盘中的3.6）。OSPF的第二个版本OSPF2已成为因特网标准协议[RFC 2328]（OSPF2的文档长达224页，而RIP2的文档才38页）。关于OSPF可参阅专著[MOY98], [HUIT95]。请注意：OSPF只是一个协议的名字，它并不表示其他的路由选择协议不是“最短路径优先”。实际上，所有的在自治系统内部使用的路由选择协议（包括RIP协议）都是要寻找一条最短的路径。

ARP：路由器与服务器通信时，将IP地址转换为MAC地址

HTTP：TCP建立完成后用HTTP协议访问网页

❓如果服务器ip地址改变了，客户端怎么知道呢

我猜是在下一次查询的时候发现本地域名服务器的缓存中并没有服务器原来的IP地址，而是存放着顶级域名服务器dns.com的IP地址。然后就去查？

✅DNS解析过程

（迭代和递归询问，忘说先查本地缓存了，没细究）

DNS解析过程

DNS域名解析过程，接收到DNS查询结果之后还做了什么？

⬆️以上都是同一个问题

📒教材

因特网的域名系统DNS被设计成为一个联机分布式数据库系统，并采用客户-服务器方式。DNS使大多数名字都在本地进行解析(resolve)[插图]，仅少量解析需要在因特网上通信，因此DNS系统的效率很高。由于DNS是分布式系统，即使单个计算机出了故障，也不会妨碍整个DNS系统的正常运行。

域名到IP地址的解析是由分布在因特网上的许多域名服务器程序（可简称为域名服务器）共同完成的。域名服务器程序在专设的结点上运行，而人们也常把运行域名服务器程序的机器也称为域名服务器。

域名到IP地址的解析过程的要点如下：

当某一个应用进程需要把主机名解析为IP地址时，该应用进程就调用解析程序(resolver)，并成为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器（使用UDP是为了减少开销）。

本地域名服务器在查找域名后，把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。

若本地域名服务器不能回答该请求，则此域名服务器就暂时成为DNS中的另一个客户，并向其他域名服务器发出查询请求。这种过程直至找到能够回答该请求的域名服务器为止。上述这种查找过程，后面还要进一步讨论。

假定域名为m.xyz.com的主机想知道另一个主机（域名为y.abc.com）的IP地址。例如，主机m.xyz.com打算发送邮件给主机y.abc.com。这时就必须知道主机y.abc.com的IP地址。下面是图6-5(a)的几个查询步骤：

主机，本地，根，顶级，权限，权限最终告诉本地，ip是什么，然后本地告诉主机。

❶ 主机m.xyz.com先向其本地域名服务器dns.xyz.com进行递归查询。

❷ 本地域名服务器采用迭代查询。它先向一个根域名服务器查询。// 通常是迭代，也可以设置递归，这个是可以配置的

❸ 根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.com的IP地址。

❹ 本地域名服务器向顶级域名服务器dns.com进行查询。

❺顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.abc.com的IP地址。

❻ 本地域名服务器向权限域名服务器dns.abc.com进行查询。

❼ 权限域名服务器dns.abc.com告诉本地域名服务器，所查询的主机的IP地址。

❽ 本地域名服务器最后把查询结果告诉主机m.xyz.com。

我们注意到，这8个步骤总共要使用8个UDP用户数据报的报文。本地域名服务器经过三次迭代查询后，从权限域名服务器dns.abc.com得到了主机y.abc.com的IP地址，最后把结果返回给发起查询的主机m.xyz.com。

使用 UDP 节省开销。

📒笔记

主机向本地域名服务器的查询一般都是采用递归查询：如果主机所询问的本地域名服务器不知道被查询的域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其它根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的IP地址，或者是报错，表示无法查询到所需的IP地址。

本地域名服务器向根域名服务器的查询的迭代查询：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的IP地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的IP地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，知道了所要解析的IP地址或报错，然后把这个结果返回给发起查询的主机。

这两种查询的差别：

递归：客户端只发一次请求，要求对方给出最终结果，返回的结果只有两种:查询成功或查询失败

迭代：客户端发出一次请求，对方如果没有授权回答，它就会返回一个能解答这个查询的其它名称服务器列表，客户端会再向返回的列表中发出请求，直到找到最终负责所查域名的名称服务器，从它得到最终结果，返回的是最佳的查询点或者主机地址

授权回答：向dns服务器查询一个域名，刚好这个域名是本服务器负责，返回的结果就是授权回答。

客户端-本地dns服务端：这部分属于递归查询。

本地dns服务端-外网：这部分属于迭代查询。

下面举一个例子演示整个查询过程：

​ 假定域名为m.xyz.com的主机想知道另一个主机y.abc.com的IP地址。下面是上图a的几个查询步骤：

​ 1、主机m.abc.com先向本地服务器dns.xyz.com进行递归查询。

​ 2、本地服务器采用迭代查询。它先向一个根域名服务器查询。

​ 3、根域名服务器告诉本地服务器，下一次应查询的顶级域名服务器dns.com的IP地址。

​ 4、本地域名服务器向顶级域名服务器dns.com进行查询。

​ 5、顶级域名服务器dns.com告诉本地域名服务器，下一步应查询的权限域名服务器dns.abc.com的IP地址。

​ 6、本地域名服务器向权限域名服务器dns.abc.com进行查询。

​ 7、权限域名服务器dns.abc.com告诉本地域名服务器，所查询的主机的IP地址。

​ 8、本地域名服务器最后把查询结果告诉m.xyz.com。

​ 整个查询过程共用到了8个UDP报文。

✅DNS缓存

DNS缓存存在哪？有效期多少？可以设置吗？

📒教材

为了提高DNS查询效率，并减轻根域名服务器的负荷和减少因特网上的DNS查询报文数量，在域名服务器中广泛地使用了高速缓存（有时也称为高速缓存域名服务器）。高速缓存用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

例如，在图6-5(a)的查询过程中，如果在不久前已经有用户查询过域名为y.abc.com的IP地址，那么本地域名服务器就不必向根域名服务器重新查询y.abc.com的IP地址，而是直接把高速缓存中存放的上次查询结果（即y.abc.com的IP地址）告诉用户。

假定本地域名服务器的缓存中并没有y.abc.com的IP地址，而是存放着顶级域名服务器dns.com的IP地址，那么本地域名服务器也可以不向根域名服务器进行查询，而是直接向com顶级域名服务器发送查询请求报文。这样不仅可以大大减轻根域名服务器的负荷，而且也能够使因特网上的DNS查询请求和回答报文的数量大为减少。

由于名字到地址的绑定[插图]并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如，每个项目只存放两天）。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息，就必须重新到授权管理该项的域名服务器获取绑定信息。当权限域名服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。

增加此时间值可减少网络开销，而减少此时间值可提高域名转换的准确性。

✅GET和POST的区别

get和post的区别，证书

http get 和 post

GET和POST的区别

Get请求和Post请求的区别。注意Get请求比Post请求效率高，Post请求需要服务器返回100再发送数据处理，Get请求直接是通过URL。

• GET把参数包含在URL中，POST通过request body传递参数

• GET产生一个TCP数据包；POST产生两个TCP数据包。

• GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

• POST方式的请求，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

（1）定义：Get 方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。比如，打开一个链接，浏览器就会发送 GET 请求给服务器，服务器就会返回链接中所有文字及资源。而 POST 方法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报文的 body 里。比如，在某链接中敲入了留言后点击「提交」，浏览器就会执行一次 POST 请求，把留言文字放进了报文 body 里，然后拼接好 POST 请求头，通过 TCP 协议发送给服务器。

（2）安全和幂等：安全和幂等的概念【在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。】那么很明显 GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。

✅TCP连接保持 keepalive

这个好像问的不多哦。可以大概了解一下就行。

浏览器渲染页面完成后会保持TCP连接吗【根据Connection请求头，若为keep-alive则保持】

保活检测

TCP Keepalive起源

TCP协议中有长连接和短连接之分。短连接环境下，数据交互完毕后，主动释放连接；

长连接的环境下，进行一次数据交互后，很长一段时间内无数据交互时，客户端可能意外断电、死机、崩溃、重启，还是中间路由网络无故断开，这些TCP连接并未来得及正常释放，那么，连接的另一方并不知道对端的情况，它会一直维护这个连接，长时间的积累会导致非常多的半打开连接，造成端系统资源的消耗和浪费，且有可能导致在一个无效的数据链路层面发送业务数据，结果就是发送失败。所以服务器端要做到快速感知失败，减少无效链接操作，这就有了TCP的Keepalive（保活探测）机制。

TCP Keepalive作用

1. 探测连接的对端是否存活

在应用交互的过程中，可能存在以下几种情况：

（1）客户端或服务器意外断电，死机，崩溃，重启。

（2）中间网络已经中断，而客户端与服务器并不知道。

利用保活探测功能，可以探知这种对端的意外情况，从而保证在意外发生时，可以释放半打开的TCP连接。

1. 防止中间设备因超时删除连接相关的连接表

中间设备如防火墙等，会为经过它的数据报文建立相关的连接信息表，并为其设置一个超时时间的定时器，如果超出预定时间，某连接无任何报文交互的话，中间设备会将该连接信息从表中删除，在删除后，再有应用报文过来时，中间设备将丢弃该报文，从而导致应用出现异常。

TCP Keepalive可能导致的问题

Keepalive 技术只是 TCP 技术中的一个可选项。因为不当的配置可能会引起一些问题，所以默认是关闭的。

可能导致下列问题：

\1. 在短暂的故障期间，Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接

\2. 需要消耗额外的宽带和流量

\3. 在以流量计费的互联网环境中增加了费用开销

TCP Keepalive HTTP Keep-Alive 的关系

很多人会把TCP Keepalive 和 HTTP Keep-Alive 这两个概念搞混淆。

这里简单介绍下HTTP Keep-Alive 。

在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。

但从 HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加上Connection、Keep-Alive字段.

✅cookie和session

📒教材6.4.3 Part4

在本节第1小节“HTTP的操作过程”已经讲过，HTTP是无状态的。这样做虽然简化了服务器的设计，但在实际工作中，一些万维网站点却常常希望能够识别用户。例如，在网上购物时，一个顾客要购买多种物品。当他把选好的一件物品放入“购物车”后，他还要继续浏览和选购其他物品。因此，服务器需要记住用户的身份，使他再接着选购的一些物品能够放入同一个“购物车”中，这样就便于集中结账。有时某些万维网站点也可能想限制某些用户的访问。要做到这点，可以在HTTP中使用Cookie。在RFC 2109中对Cookie进行了定义，规定万维网站点可以使用Cookie来跟踪用户。Cookie原意是“小甜饼”（广东人用方言音译为“曲奇”），目前尚无标准译名，在这里Cookie表示在HTTP服务器和客户之间传递的状态信息。现在很多网站都已广泛使用Cookie。

👉Cookie概念

在浏览某些网站时,这些网站会把一些数据存在客户端 , 用于使用网站等跟踪用户,实现用户自定义功能.

是否设置过期时间：如果不设置过期时间,则表示这个 Cookie生命周期为浏览器会话期间, 只要关闭浏览器,cookie就消失了.

这个生命期为浏览会话期的cookie,就是会话Cookie;

存储：一般保存在内存,不在硬盘;

如果设置了过期时间, 浏览器会把cookie保存在硬盘上,关闭再打开浏览器, 这些cookie 依然有效直到 超过的设置过期时间;

存储在硬盘上的Cookie可以在不同的浏览器进程间共享，比如两个IE窗口。

而对于保存 在内存的Cookie，不同的浏览器有不同的处理方式。

👉session

Session 是存放在服务器端的类似于HashTable结构（每一种web开发技术的实现可能不一样，下文直接称之为HashTable）来存放用户数据;

作用：实现网页之间数据传递，是一个存储在服务器端的对象集合。

原理：当用户请求一个Asp.net页面时，系统将自动创建一个Session;退出应用程序或关闭服务器时，该Session撤销。系统在创建Session时将为其分配一个长长的字符串标识，以实现对Session进行管理与跟踪。

session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

保存:存储在Server段的内存进程中的，而这个进程相当不稳定，经常会重启，这样重启的话，就会造成Session失效，用户就必须要重新登录，用户体验相当差，比如用户在填写资料，快要结束的时候Session失效，直接跳到登录页面;

👉区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上.

简单的说，当你登录一个网站的时候，如果web服务器端使用的是session,那么所有的数据都保存在服务器上面，客户端每次请求服务器的时候会发送 当前会话的session_id，服务器根据当前session_id判断相应的用户数据标志，以确定用户是否登录，或具有某种权限。

由于数据是存储在服务器 上面，所以你不能伪造，但是如果你能够获取某个登录用户的session_id，用特殊的浏览器伪造该用户的请求也是能够成功的。

session_id是服务器和客户端链接时候随机分配的，一般来说是不会有重复，但如果有大量的并发请求，也不是没有重复的可能性，我曾经就遇到过一次。

登录某个网站，开始显示的 是自己的信息，等一段时间超时了，一刷新，居然显示了别人的信息。

Session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID 为标识符来存取服务器端的Session存储空间。而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一 SessionID提交到服务器端，来存取Session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用Cookie，那么Session也会失效。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗。考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)

Socket

socket创建流程

前面已经讲过，每一条TCP连接有两个端点。那么，TCP连接的端点是什么呢？不是主机，不是主机的IP地址，不是应用进程，也不是运输层的协议端口，TCP连接的端点叫做套接字(socket)或插口。根据RFC 793的定义：端口号拼接到(contatenated with) IP地址即构成了套接字。因此，套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔开。例如，若IP地址是192.3.4.5而端口号是80，那么得到的套接字就是(192.3.4.5: 80)。总之，我们有

// 图挂

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定。即：

// 图挂待补

这里IP1和IP2分别是两个端点主机的IP地址，而port1和port2分别是两个端点主机中的端口号。TCP连接的两个套接字就是socket1和socket2。可见套接字socket是个很抽象的概念。在下一章的6.8节还要对套接字进行更多的介绍。

其他不太清楚啦。

❓谈谈对token的理解

不知道

我就记得之前实习的时候好像给了我一个token

然后每次我访问服务器的时候就要我输入这个玩意上的动态码

https://zh.wikipedia.org/zh-cn/%E5%AE%89%E5%85%A8%E4%BB%A4%E7%89%8C

安全令牌（英语：Security token），又译安全性令牌，也被称为硬件令牌（hardware token）、授权令牌（authentication token）、USB令牌（USB token）、加密令牌（cryptographic token）、虚拟令牌（virtual token）、钥匙卡（key fob）等。是一种硬件设备，用来作为身份验证，让电脑系统的用户可以访问系统资源。这也被用来称呼软件令牌。

就是用于身份验证的吧

离职的时候还差点弄丢了

✅网络协议有了解吗？

这算是一个很大的问题

看要怎么切入比较好

可以从上到下展开讲讲：

应用层、传输层、网络层、数据链路层、物理层

✅分析一个URL其中各字段的含义

📒教材

统一资源定位符URL是用来表示从因特网上得到的资源位置和访问这些资源的方法。URL给资源的位置提供一种抽象的识别方法，并用这种方法给资源定位。只要能够对资源定位，系统就可以对资源进行各种操作，如存取、更新、替换和查找其属性。

这里所说的“资源”是指在因特网上可以被访问的任何对象，包括文件目录、文件、文档、图像、声音等，以及与因特网相连的任何形式的数据。“资源”还包括电子邮件的地址和USENET新闻组[插图]，或USENET新闻组中的报文。

URL相当于一个文件名在网络范围的扩展。因此，URL是与因特网相连的机器上的任何可访问对象的一个指针。由于访问不同对象所使用的协议不同，所以URL还指出读取某个对象时所使用的协议。URL的一般形式由以下四个部分组成：

<协议>://<主机>:<端口>/<路径>

https://www.baidu.com:443/index.html

http://www.baidu.com:80/index.html

URL的第一部分是最左边的<协议>。这里的<协议>就是指出使用什么协议来获取该万维网文档。现在最常用的协议就是http（超文本传送协议HTTP），其次是ftp（文件传送协议FTP）。在<协议>后面是规定必须写上的格式“://”，不能省略。

它的右边是第二部分<主机>，它指出这个万维网文档是在哪一个主机上。这里的<主机>就是指该主机在因特网上的域名。

再后面是第三和第四部分<端口>和<路径>，有时可省略。下面我们简单介绍使用得最多的一种URL。

对于万维网的网点的访问要使用HTTP协议。HTTP的URL的一般形式是：http://<主机>:<端口>/<路径>

HTTP的默认端口号是80，通常可省略。若再省略文件的<路径>项，则URL就指到因特网上的某个主页(home page)。主页是个很重要的概念，它可以是以下几种情况之一：

(1) 一个WWW服务器的最高级别的页面。

(2) 某一个组织或部门的一个定制的页面或目录。从这样的页面可链接到因特网上的与本组织或部门有关的其他站点。

(3) 由某一个人自己设计的描述他本人情况的WWW页面。

例如，要查有关清华大学的信息，就可先进入到清华大学的主页，其URL为[插图]：http://www.tsinghua.edu.cn这里省略了默认的端口号80。我们从清华大学的主页入手，就可以通过许多不同的链接找到所要查找的各种有关清华大学各个部门的信息。

一个TCP连接可以发多少个HTTP请求

https://www.jianshu.com/p/aaba68b87416

✅堆栈

多线程中栈与堆是公有的还是私有的

在多线程环境下，每个线程拥有一个栈和一个程序计数器。栈和程序计数器用来保存线程的执行历史和线程的执行状态，是线程私有的资源。其他的资源（比如堆、地址空间、全局变量）是由同一个进程内的多个线程共享。

地址从低到高：代码区、常量区、全局区（数据段）、堆空间、栈空间、动态库

• 代码区：存放函数体的二进制代码

• 常量区：常量字符串就是放在这里的。程序结束后由系统释放

• 全局区（静态区）：全局变量和静态变量的存储是放在一块的，初始化的全局变量和静态变量在一块区域， 未初始化的全局变量和未初始化的静态变量在相邻的另一块区域。 程序结束后由系统释放。

• 堆空间：一般由程序员分配释放，若程序员不释放，程序结束时可能由OS回收。与数据结构中的堆是两回事，分配方式倒是类似于链表

• 栈空间：由操作系统自动分配释放，存放函数的参数值，局部变量的值，其操作方式类似于数据结构中的栈。

堆和栈的区别：

一、堆栈空间分配区别：

• 堆（操作系统）： 一般由程序员分配释放， 若程序员不释放，程序结束时可能由OS回收，分配方式倒是类似于链表。

• 栈（操作系统）：由操作系统自动分配释放 ，存放函数的参数值，局部变量的值等。其操作方式类似于数据结构中的栈；

二、堆栈缓存方式区别：

• 堆是存放在二级缓存，生命周期由虚拟机的垃圾回收算法来决定（并不是一旦成为孤儿对象就能被回收）。所以调用这些对象的速度要相对来得低一些。

• 栈使用的是一级缓存， 他们通常都是被调用时处于存储空间中，调用完毕立即释放；

堆：内存中，存储的是引用数据类型，引用数据类型无法确定大小，堆实际上是一个在内存中使用到内存中零散空间的链表结构的存储空间，堆的大小由引用类型的大小直接决定，引用类型的大小的变化直接影响到堆的变化

栈：是内存中存储值类型的，大小为2M，超出则会报错，内存溢出

三、堆栈数据结构区别：

堆（数据结构）：堆可以被看成是一棵树，如：堆排序；

栈（数据结构）：一种先进后出的数据结构。

堆栈是两种数据结构。堆栈都是一种数据项按序排列的数据结构，只能在一端(称为栈顶(top))对数据项进行插入和删除。在单片机应用中，堆栈是个特殊的存储区，主要功能是暂时存放数据和地址，通常用来保护断点和现场。要点：堆，队列优先,先进先出（FIFO—first in first out）。栈，先进后出(FILO—First-In/Last-Out)。

✅C/S模型，socket的建立过程(bind/listen那一套，顺便说了accept和connect是在tcp握手的什么时间返回)

socket的基本操作

既然socket是“open—write/read—close”模式的一种实现，那么socket就提供了这些操作对应的函数接口。下面以TCP为例，介绍几个基本的socket接口函数。

1、socket()函数

int socket(int domain, int type, int protocol);

socket函数对应于普通文件的打开操作。普通文件的打开操作返回一个文件描述字，而socket()用于创建一个socket描述符（socket descriptor），它唯一标识一个socket。这个socket描述字跟文件描述字一样，后续的操作都有用到它，把它作为参数，通过它来进行一些读写操作。

正如可以给fopen的传入不同参数值，以打开不同的文件。创建socket的时候，也可以指定不同的参数创建不同的socket描述符，socket函数的三个参数分别为：

domain：即协议域，又称为协议族（family）。常用的协议族有，AF_INET、AF_INET6、AF_LOCAL（或称AF_UNIX，Unix域socket）、AF_ROUTE等等。协议族决定了socket的地址类型，在通信中必须采用对应的地址，如AF_INET决定了要用ipv4地址（32位的）与端口号（16位的）的组合、AF_UNIX决定了要用一个绝对路径名作为地址。

type：指定socket类型。常用的socket类型有，SOCK_STREAM、SOCK_DGRAM、SOCK_RAW、SOCK_PACKET、SOCK_SEQPACKET等等（socket的类型有哪些？）。

protocol：故名思意，就是指定协议。常用的协议有，IPPROTO_TCP、IPPTOTO_UDP、IPPROTO_SCTP、IPPROTO_TIPC等，它们分别对应TCP传输协议、UDP传输协议、STCP传输协议、TIPC传输协议（这个协议我将会单独开篇讨论！）。

注意：并不是上面的type和protocol可以随意组合的，如SOCK_STREAM不可以跟IPPROTO_UDP组合。当protocol为0时，会自动选择type类型对应的默认协议。

当我们调用socket创建一个socket时，返回的socket描述字它存在于协议族（address family，AF_XXX）空间中，但没有一个具体的地址。如果想要给它赋值一个地址，就必须调用bind()函数，否则就当调用connect()、listen()时系统会自动随机分配一个端口。

2、bind()函数

正如上面所说bind()函数把一个地址族中的特定地址赋给socket。例如对应AF_INET、AF_INET6就是把一个ipv4或ipv6地址和端口号组合赋给socket。

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

函数的三个参数分别为：

sockfd：即socket描述字，它是通过socket()函数创建了，唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。

addr：一个const struct sockaddr *指针，指向要绑定给sockfd的协议地址。这个地址结构根据地址创建socket时的地址协议族的不同而不同，如ipv4对应的是：

struct sockaddr_in {

sa_family_t sin_family; / address family: AF_INET /

in_port_t sin_port; / port in network byte order /

struct in_addr sin_addr; / internet address /

};

/ Internet address. /

struct in_addr {

uint32_t s_addr; / address in network byte order /

};

ipv6对应的是：

struct sockaddr_in6 {

sa_family_t sin6_family; / AF_INET6 /

in_port_t sin6_port; / port number /

uint32_t sin6_flowinfo; / IPv6 flow information /

struct in6_addr sin6_addr; / IPv6 address /

uint32_t sin6_scope_id; / Scope ID (new in 2.4) /

};

struct in6_addr {

unsigned char s6_addr[16]; / IPv6 address /

};

Unix域对应的是：

#define UNIX_PATH_MAX 108

struct sockaddr_un {

sa_family_t sun_family; / AF_UNIX /

char sun_path[UNIX_PATH_MAX]; / pathname /

};

addrlen：对应的是地址的长度。

通常服务器在启动的时候都会绑定一个众所周知的地址（如ip地址+端口号），用于提供服务，客户就可以通过它来接连服务器；而客户端就不用指定，有系统自动分配一个端口号和自身的ip地址组合。这就是为什么通常服务器端在listen之前会调用bind()，而客户端就不会调用，而是在connect()时由系统随机生成一个。

网络字节序与主机字节序

主机字节序就是我们平常说的大端和小端模式：不同的CPU有不同的字节序类型，这些字节序是指整数在内存中保存的顺序，这个叫做主机序。引用标准的Big-Endian和Little-Endian的定义如下：

a) Little-Endian就是低位字节排放在内存的低地址端，高位字节排放在内存的高地址端。

b) Big-Endian就是高位字节排放在内存的低地址端，低位字节排放在内存的高地址端。

网络字节序：4个字节的32 bit值以下面的次序传输：首先是0～7bit，其次8～15bit，然后16～23bit，最后是24~31bit。这种传输次序称作大端字节序。由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序。字节序，顾名思义字节的顺序，就是大于一个字节类型的数据在内存中的存放顺序，一个字节的数据没有顺序的问题了。

所以：在将一个地址绑定到socket的时候，请先将主机字节序转换成为网络字节序，而不要假定主机字节序跟网络字节序一样使用的是Big-Endian。由于这个问题曾引发过血案！公司项目代码中由于存在这个问题，导致了很多莫名其妙的问题，所以请谨记对主机字节序不要做任何假定，务必将其转化为网络字节序再赋给socket。

3、listen()、connect()函数

如果作为一个服务器，在调用socket()、bind()之后就会调用listen()来监听这个socket，如果客户端这时调用connect()发出连接请求，服务器端就会接收到这个请求。

int listen(int sockfd, int backlog);

int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

listen函数的第一个参数即为要监听的socket描述字，第二个参数为相应socket可以排队的最大连接个数。socket()函数创建的socket默认是一个主动类型的，listen函数将socket变为被动类型的，等待客户的连接请求。

connect函数的第一个参数即为客户端的socket描述字，第二参数为服务器的socket地址，第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。

4、accept()函数

TCP服务器端依次调用socket()、bind()、listen()之后，就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就想TCP服务器发送了一个连接请求。TCP服务器监听到这个请求之后，就会调用accept()函数取接收请求，这样连接就建立好了。之后就可以开始网络I/O操作了，即类同于普通文件的读写I/O操作。

int accept(int sockfd, struct sockaddr addr, socklen_t addrlen);

accept函数的第一个参数为服务器的socket描述字，第二个参数为指向struct sockaddr *的指针，用于返回客户端的协议地址，第三个参数为协议地址的长度。如果accpet成功，那么其返回值是由内核自动生成的一个全新的描述字，代表与返回客户的TCP连接。

注意：accept的第一个参数为服务器的socket描述字，是服务器开始调用socket()函数生成的，称为监听socket描述字；而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字，它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字，当服务器完成了对某个客户的服务，相应的已连接socket描述字就被关闭。

5、read()、write()等函数

万事具备只欠东风，至此服务器与客户已经建立好连接了。可以调用网络I/O进行读写操作了，即实现了网咯中不同进程之间的通信！网络I/O操作有下面几组：

read()/write()

recv()/send()

readv()/writev()

recvmsg()/sendmsg()

recvfrom()/sendto()

我推荐使用recvmsg()/sendmsg()函数，这两个函数是最通用的I/O函数，实际上可以把上面的其它函数都替换成这两个函数。它们的声明如下：

​ #include

​ ssize_t read(int fd, void *buf, size_t count);

​ ssize_t write(int fd, const void *buf, size_t count);

​ #include <sys/types.h>

​ #include <sys/socket.h>

​ ssize_t send(int sockfd, const void *buf, size_t len, int flags);

​ ssize_t recv(int sockfd, void *buf, size_t len, int flags);

​ ssize_t sendto(int sockfd, const void *buf, size_t len, int flags,

​ const struct sockaddr *dest_addr, socklen_t addrlen);

​ ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags,

​ struct sockaddr src_addr, socklen_t addrlen);

​ ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);

​ ssize_t recvmsg(int sockfd, struct msghdr *msg, int flags);

read函数是负责从fd中读取内容.当读成功时，read返回实际所读的字节数，如果返回的值是0表示已经读到文件的结束了，小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的，如果是ECONNREST表示网络连接出了问题。

write函数将buf中的nbytes字节内容写入文件描述符fd.成功时返回写的字节数。失败时返回-1，并设置errno变量。 在网络程序中，当我们向套接字文件描述符写时有俩种可能。1)write的返回值大于0，表示写了部分或者是全部的数据。2)返回的值小于0，此时出现了错误。我们要根据错误类型来处理。如果错误为EINTR表示在写的时候出现了中断错误。如果为EPIPE表示网络连接出现了问题(对方已经关闭了连接)。

其它的我就不一一介绍这几对I/O函数了，具体参见man文档或者baidu、Google，下面的例子中将使用到send/recv。

6、close()函数

在服务器与客户端建立连接之后，会进行一些读写操作，完成了读写操作就要关闭相应的socket描述字，好比操作完打开的文件要调用fclose关闭打开的文件。

#include

int close(int fd);

close一个TCP socket的缺省行为时把该socket标记为以关闭，然后立即返回到调用进程。该描述字不能再由调用进程使用，也就是说不能再作为read或write的第一个参数。

注意：close操作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求。

❓跨域问题如何解决

不知道

❓ip头都有啥内容

✅什么是子网掩码、它的作用是什么

IP地址分类清楚吗？子网是怎么划分的，什么是子网掩码？

1. 分类：IP 地址 ::= {< 网络号 >, < 主机号 >}**

   

   A类网络的IP地址范围为：1.0.0.1－126.255.255.254；

   B类网络的IP地址范围为：128.1.0.1－191.255.255.254； 127.x.x.x用作本地软件环回测试

   C类网络的IP地址范围为：192.0.1.1－223.255.255.254

2. 子网划分

   通过在主机号字段中拿一部分作为子网号，把两级 IP 地址划分为三级 IP 地址。

   IP 地址 ::= {< 网络号 >, < 子网号 >, < 主机号 >}

   要使用子网，必须配置子网掩码。一个 B 类地址的默认子网掩码为 255.255.0.0，如果 B 类地址的子网占两个比特，那么子网掩码为 11111111 11111111 11000000 00000000，也就是 255.255.192.0。外部网络看不到子网的存在。

   子网掩码是一个32位地址,是与IP地址结合使用的一种技术。它的主要作用有两个,

   一是用于屏蔽IP地址的一部分以区别网络标识和主机标识,并说明该IP地址是在局域网上,还是在远程网上。

   二是用于将一个大的IP网络划分为若干小的子网络。 使用子网是为了减少IP的浪费。

3. 无分类编址 CIDR

   IP 地址 ::= {< 网络前缀号 >, < 主机号 >}

   CIDR 消除了传统 A 类、B 类和 C 类地址以及划分子网的概念，使用网络前缀和主机号来对 IP 地址进行编码，网络前缀的长度可以根据需要变化。CIDR 的记法上采用在 IP 地址后面加上网络前缀长度的方法，例如 128.14.35.7/20 表示前 20 位为网络前缀。

   CIDR 的地址掩码可以继续称为子网掩码，子网掩码首 1 长度为网络前缀的长度。 一个 CIDR 地址块中有很多地址，一个 CIDR 表示的网络就可以表示原来的很多个网络，并且在路由表中只需要一个路由就可以代替原来的多个路由，减少了路由表项的数量。把这种通过使用网络前缀来减少路由表项的方式称为路由聚合，也称为 构成超网 。

   在路由表中的项目由“网络前缀”和“下一跳地址”组成，在查找时可能会得到不止一个匹配结果，应当采用最长前缀匹配来确定应该匹配哪一个。

✅如何将一个长URL转换为一个短URL

如何将一个长URL转换为一个短URL

HTTP重定向

URL 重定向，也称为 URL 转发，是一种当实际资源，如单个页面、表单或者整个 Web 应用被迁移到新的 URL 下的时候，保持（原有）链接可用的技术。HTTP 协议提供了一种特殊形式的响应—— HTTP 重定向（HTTP redirects）来执行此类操作。

HTTP重定向：服务器无法处理浏览器发送过来的请求（request），服务器告诉浏览器跳转到可以处理请求的url上。（浏览器会自动访问该URL地址，以至于用户无法分辨是否重定向了。） 重定向的返回码3XX说明。Location响应首部包含了内容的新地址或是优选地址的URL。

状态码 301：在请求的URL已被移除时使用。响应的Location首部中应该包含资源现在所处的URL。 302：与301状态码类似，但是，客户端应该使用Location首部给出的URL来零食定位资源，将来的请求仍然使用老的URL。

官方的比较简洁的说明：

301 redirect: 301 代表永久性转移(Permanently Moved) 302 redirect: 302 代表暂时性转移(Temporarily Moved ) 尽量使用301跳转！301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。

✅对称加密秘钥和非对称加密秘钥有哪些

// 这个题好，问密钥的

对称密钥加密 - 百度百科

对称密钥加密又叫专用密钥加密或共享密钥加密，即发送和接收数据的双方必使用相同的密钥对明文进行加密和解密运算。对称密钥加密算法主要包括：DES、3DES、IDEA、RC5、RC6等。

非对称密钥加密（也叫公开密钥加密）

该加密算法使用两个不同的密钥：加密密钥和解密密钥。

与对称密钥加密相比，优点在于无需共享的通用密钥，解密的私钥不发往任何用户。即使公钥在网上被截获，如果没有与其匹配的私钥，也无法解密，所截获的公钥是没有任何用处的。

常见的公钥加密算法有： [2] RSA、ElGamal、背包算法、Rabin（RSA的特例）、迪菲－赫尔曼密钥交换协议中的公钥加密算法、椭圆曲线加密算法（Elliptic Curve Cryptography, ECC）。使用最广泛的是RSA算法（由发明者Rivest、Shmir和Adleman姓氏首字母缩写而来）是著名的公开金钥加密算法，ElGamal是另一种常用的非对称加密算法。

✅加密算法具体的过程了解吗

• 知道哪些加密算法

• 私钥的发送方式（不知道 随便编的）

👉对称密钥加密过程

假设A需要把一份明文为M的资料发给B，但是因为怕资料在传输的中途被窃听或者篡改，A用了对称加密法将M经过一个加密函数 f 处理后生成M'加密，而B接受到加密文后通过事先商定好的 f 再次处理M'便可以还原成明文M，从而达到安全传输信息的目的。

👉非对称密钥加密过程

假设两个用户A向B发送信息，B的公钥为c，对应私钥（也是属于B的）为d，明文为x。

1. A用公钥对明文进行加密形成密文c(x)，然后传输密文；

2. B收到密文，用私钥对密文进行解密d(c(x))，得到要通信的明文x。

B向A发送信息反之。

❓基于TCP的socket通信如何工作？

能现场写下吗

✅如果很多的客户和服务器连接，会建立几个TCP连接

1. HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

2. HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection。在同一个TCP的连接中可以传送多个HTTP请求和响应。多个请求和响应可以重叠，多个请求和响应可以同时进行。更加多的请求头和响应头(比如HTTP1.0没有host的字段)。

3. HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。

4. 多路复用

HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟，大幅度提高了连接的利用率。举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。

✅HTTPS通信方式简述

通信流程？

• 客户端向服务端发起建立HTTPS请求。

• 服务器向客户端发送数字证书。

• 客户端验证数字证书，证书验证通过后客户端生成会话密钥（双向验证则此处客户端也会向服务器发送证书）。

• 服务器生成会话密钥（双向验证此处服务端也会对客户端的证书验证）。

• 客户端与服务端开始进行加密会话。

✅SSL握手

ssl加密以及加密算法

HTTPS 的SSL握手详细过程

（与图上的数字不是一一对应的）

① 客户端的浏览器向服务器发送请求，并传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

② 服务器向客户端传送证书、 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息。

③ 客户端利用服务器传过来的信息验证服务器的合法性（由客户端的 TLS 来完成的），合法性检验包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的 "发行者的数字签名"，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开。

④ 客户端随机产生一个用于通讯的对称加密密钥，用服务器的公钥对其加密（②中服务器证书中获得这个非对称加密密钥），然后将加密信息传给服务器，这是为了让服务端得到这个密钥，之后的通信可以通过这个对称加密密钥来进行加密。如果服务器要求客户的身份认证（在握手过程中为可选）：

• 客户端建立一个随机数然后对其进行数据签名，将这个含有签名的随机数、客户自己的证书、加密过的对称加密密钥密钥一起传给服务器。

• 服务器检验客户端证书和签名随机数的合法性，合法性验证包括：客户的证书使用日期是否有效，为客户提供证书的 CA 是否可靠，发行 CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断。

⑤ 服务器用私钥解密得到对称加密密钥，之后客户端和服务端的通信就可以通过这个密钥来进行加密解密了。

⑥ 服务器和客户端用对称加密密钥来进行 SSL 协议的安全数据通讯的加解密通讯，在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

• 客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤 ⑦ 中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

• 服务器向客户端发出信息，指明后面的数据通讯将使用的步骤 ⑦ 中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。

⑦ SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

✅HTTPS算法加密有哪些，对称么？

HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

只用非对称加密通信不行吗：不行，数据量很大时候用非对称加密会非常慢

认证：使用数字证书认证机构来对通信方进行认证。将服务器公钥放入到数字证书中，解决了冒充的风险。需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

（2）加密：混合加密。【传输数据用对称加密方式，对称加密生成的秘钥用非对称加密方式】

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

l 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。

l 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

l 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。

l 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

整体过程：客户端和服务端在开始传输数据之前，会协商传输过程需要使用的加密算法。客户端发送协商请求给服务端, 其中包含自己支持的非对成加密的密钥交换算法 ( 一般是RSA), 数据签名摘要算法 ( 一般是SHA或者MD5) , 加密传输数据的对称加密算法 ( 一般是DES),以及加密密钥的长度。 服务端接收到消息之后，选中安全性最高的算法，并将选中的算法发送给客户端，完成协商。客户端生成随机的字符串，通过协商好的非对称加密算法，使用服务端的公钥对该字符串进行加密，发送给服务端。 服务端接收到之后，使用自己的私钥解密得到该字符串。在随后的数据传输当中，使用这个字符串作为密钥进行对称加密。 （3）完整性保护：SSL 提供报文摘要功能来进行完整性保护。HTTP 也提供了 MD5 报文摘要功能，但不是安全的。摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。 https缺点：贵，慢，安全范围有限，ssl证书需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

✅为什么说http是无状态的？

（cookie和session相关

无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。

无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。这样每操作一次，都要验证信息，这样的购物体验还能愉快吗？别问，问就是酸爽！对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。

❓你认为tcp三次握手现在有什么不完善的地方

✅HTTPS的实现机制

// 就讲访问一个url的过程就好了

就是在问HTTPS的实现原理啦

https://www.jianshu.com/p/b1538c758c4a

✅什么时候会出现304 Not Modified

304（未修改）自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。如果网页自请求者上次请求后再也没有更改过，您应将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。服务器可以告诉 Googlebot 自从上次抓取后网页没有变更，进而节省带宽和开销。

✅打开网站比较慢，分析一下原因。

没有缓存，第一次访问

https://blog.csdn.net/u012999985/article/details/50005109

✅如果你要写一个ios的推送，用TCP还是UDP

（肯定TCP）（但是其实qq微信这种消息都是UDP发，要不然服务器负载太重，一般是用UDP配合TCP来发消息）

❓当今网络状况已经比较好了，刚才谈到的慢启动过程可能会制约网络性能，我们有什么办法解决它

https://blog.csdn.net/yusiguyuan/article/details/21458135

如何避免慢启动，进而提升性能

很简单，尽量把大量小文件放在一个TCP连接中排队传输。起初的一两个文件处于慢启动过程传输，后续的文件传输全部处于高速通道中传输，用这样的方式来减少发包的数目，进而降低时间消耗。 题外话，实际上这种传输策略带来的性能提升的功劳不仅仅归于避免慢启动，事实上也避免了大量的3次握手和四次握手，这个对海量小文件传输的性能消耗也非常致命，但是这是另一个问题，本篇不多加介绍。 随着多核服务器的兴起，以及现代网卡的多通道技术的迅猛发展，现在我们解决这一问题的通常做法是绑定多CPU的多核到网卡的多个通道，然后由CPU的核来均分传输这些小文件，每个核用一个TCP连接来排队发送分到的小文件。 讲到这儿，我想大家对于大文件的传输策略应该也心里有数了，（不考虑网卡带宽的前提下）就是分块传输，在目标机器合并。

❓TCP需要建立连接，我们有没有什么办法不去建立连接进行通信

UDP呀

用户数据报协议 UDP（User Datagram Protocol）是无连接的，尽最大可能交付，没有拥塞控制，面向报文（对于应用程序传下来的报文不合并也不拆分，只是添加 UDP 首部），支持一对一、一对多、多对一和多对多的交互通信。