参照：

https://yihuiblog.top/browser-working/L2.html

https://mp.weixin.qq.com/s/-IOy2hXd-AcuIQ02saf6Rw

https://www.cnblogs.com/yaochunhui/p/14175396.html

https://blog.csdn.net/weixin_39829073/article/details/112907168

基础知识

1. OSI与TCP/IP 模型

OSI七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

TCP/IP五层：物理层、数据链路层、网络层、传输层、应用层

七层网络体系结构各层的次要性能：

  • 应用层：为应用程序提供交互服务。在互联网中的应用层协定很多，如域名零碎DNS， 反对万维网利用的HTTP协定，反对电子邮件的SMTP协定等。
  • 表示层：次要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。
  • 会话层：负责在网络中的两节点之间建设、维持和终止通信，如服务器验证用户登录便是由会话层实现的。
  • 运输层：有时也译为传输层，向主机过程提供通用的数据传输服务。该层次要有以下两种协定:
    • TCP：提供面向连贯的、牢靠的数据传输服务;
    • UDP：提供无连贯的、尽最大致力的数据传输服务，但不保障数据传输的可靠性。
  • 网络层：抉择适合的路由和替换结点，确保数据及时传送。次要包含IP协定。
  • 数据链路层：数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧，并再相邻节点的链路上传送帧。
  • 物理层：实现相邻节点间比特流的通明传输，尽可能屏蔽传输介质和通信伎俩的差别。

2. 常见网络服务分层

应用层：HTTP、DNS、FTP、SMTP

传输层：TCP 、UDP

网络层：IP、ICMP 、路由器、防火墙

数据链路层：网卡、网桥、交换机

物理层：中继器、集线器

3. TCP三次握手

<img src="https://mc-web-1259409954.cos.ap-guangzhou.myqcloud.com/MyImages/202204111232193.jpeg" alt="图片" style="zoom: 80%;" />

三次握手过程：

  1. 客户端——发送带有SYN标记的数据包——服务端 一次握手 客户端进入syn_sent状态
  2. 服务端——发送带有SYN/ACK标记的数据包——客户端 二次握手 服务端进入syn_rcvd
  3. 客户端——发送带有ACK标记的数据包——服务端 三次握手 连贯就进入Established状态

为什么三次： 次要是为了建设牢靠的通信信道，保障客户端与服务端同时具备发送、接收数据的能力。

为什么两次不行？

  1. 避免已生效的申请报文又传送到了服务端，建设了多余的链接，浪费资源。
  2. 两次握手只能保障单向连贯是畅通的。（为了实现牢靠数据传输， TCP 协定的通信单方， 都必须保护一个序列号， 以标识发送进来的数据包中， 哪些是曾经被对方收到的。三次握手的过程即是通信单方 互相告知序列号起始值， 并确认对方曾经收到了序列号起始值的必经步骤；如果只是两次握手， 至少只有连贯发起方的起始序列号能被确认， 另一方抉择的序列号则得不到确认）。

4. 四次挥手过程：

  1. 客户端——发送带有FIN标记的数据包——服务端，敞开与服务端的连贯 ，客户端进入FIN-WAIT-1状态
  2. 服务端收到这个 FIN，它发回⼀ 个 ACK，确认序号为收到的序号加1，服务端就进入了CLOSE-WAIT状态
  3. 服务端——发送⼀个FIN数据包——客户端，敞开与客户端的连贯，客户端就进入FIN-WAIT-2状态
  4. 客户端收到这个 FIN，发回 ACK 报⽂确认，并将确认序号设置为收到序号加1，客户端进入TIME-WAIT状态

<img src="https://mc-web-1259409954.cos.ap-guangzhou.myqcloud.com/MyImages/202204111232185.jpeg" alt="图片" style="zoom:80%;" />

为什么四次：因为须要确保客户端与服务端的数据可能实现传输。

CLOSE-WAIT： 这种状态的含意其实是示意在期待敞开。

TIME-WAIT： 为了解决网络的丢包和网络不稳固所带来的其余问题，确保连贯方能在工夫范畴内，敞开本人的连贯。

5. 为什么连贯的时候是三次握手，敞开的时候却是四次握手?

服务器在收到客户端的FIN报文段后，可能还有一些数据要传输，所以不能马上敞开连贯，然而会做出应答，返回ACK报文段。

接下来可能会持续发送数据，在数据发送完后，服务器会向客户端发送FIN报文，示意数据曾经发送结束，申请敞开连贯。服务器的ACK和FIN个别都会离开发送，从而导致多了一次，因而一共须要四次挥手。

6. 如何查看TIME-WAIT状态的链接数量？

netstat -an | grep TIME_WAIT | wc -l  //查看连接数期待time_wait状态连接数

7. 为什么会TIME-WAIT过多？解决办法是怎么的？

可能起因：高并发短连贯的TCP服务器上，当服务器解决完申请后立即依照被动失常敞开连贯

解决：负载平衡服务器；Web服务器首先敞开来自负载平衡服务器的连贯

8. 半连贯，洪泛攻打问题以及如何解决（syn_cookie）

在三次握手的过程中，服务器为了响应一个受到的SYN报文段，会调配并初始化连贯变量和缓存，而后服务器发送一个SYN/ACK报文段进行响应，并期待客户端的ACK报文段。如果客户不发送ACK来实现该三次握手的第三步，最终(通常在一分多钟之后)服务器将终止该半开连贯并回收资源。这种TCP连贯治理协定的个性就会有这样一个破绽，攻击者发送大量的TCP SYN报文段，而不实现第三次握手的步骤。随着这种SYN报文段的一直到来，服务器一直为这些半开连贯分配资源，从而导致服务器连贯资源被耗费殆尽。这种攻打就是SYN泛供攻打。

为了应答这种攻打，当初有一种无效的进攻零碎，称为SYN cookie。SYN cookie的工作形式如下：

  1. 当服务器接管到一个SYN报文段时，它并不知道该报文段是来自一个非法的用户，还是这种SYN洪泛攻打的一部分。因为服务器不会为该报文段生成一个半开的连贯。相同，服务器生成一个初始TCP序列号，该序列号是SYN报文段的源IP地址和目标IP地址，源端口号和目标端口号以及仅有服务器晓得的机密数的简单函数(散列函数)。这种精心制作的初始序列号称为为“cookie”。服务器则发送具备这种非凡初始序号的SYN/ACK报文分组。服务器并不记忆该cookie或任何对应于SYN的其余状态信息。
  2. 如果该客户是非法的，则它将返回一个ACK报文段。当服务器收到该ACK报文段，须要验证该ACK是与后面发送的某个SYN绝对应。因为服务器并不保护无关SYN报文段的记忆，所以服务器通过应用SYN/ACK报文段中的源和目标IP地址与端口号以及机密数运行雷同的散列函数。如果这个函数的后果(cookie值)加1和在客户的ACK报文段中的确认值雷同的话，那么服务器就会认为该ACK对应于较早的SYN报文段，因而它是非法的。服务器则会生成一个套接字的全开连贯。
  3. 另一方面，如果客户没有返回一个ACK报文段，阐明之前的SYN报文段是洪泛攻打的一部分，然而它并没有对服务器产生危害，因为服务器没有为它调配任何资源。

9. 为什么客户端的TIME-WAIT状态必须期待2MSL ?

次要有两个起因:

  1. 为了保障客户端发送的最初一个ACK报文段可能达到服务器。这个ACK报文段可能失落，因此使处在LAST-ACK状态的服务器收不到确认。服务器会超时重传FIN+ACK报文段，客户端就能在2MSL工夫内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重启计时器。最好，客户端和服务器都失常进入到CLOSED状态。如果客户端在TIME-WAIT状态不期待一段时间，而是再发送完ACK报文后立刻开释连贯，那么就无奈收到服务器重传的FIN+ACK报文段，因此也不会再发送一次确认报文。这样，服务器就无奈依照失常步骤进入CLOSED状态。
  2. 避免已生效的连贯申请报文段呈现在本连贯中。客户端在发送完最初一个ACK确认报文段后，再通过工夫2MSL，就能够使本连贯继续的工夫内所产生的所有报文段都从网络中隐没。这样就能够使下一个新的连贯中不会呈现这种旧的连贯申请报文段。

10. 4g切换wifi会产生什么

当挪动设施的网络从4G切换到WiFi时，意味着IP地址变动了，那么必须要断开连接，而后从新连贯，而建设连贯的过程蕴含TCP三次握手和TLS四次挥手的时延，以及TCP慢启动的加速过程，给用户的感觉就是忽然网络卡顿了一下，所以说，迁徙的老本是很高的。

http3是怎么解决连贯迁徙

HTTP3中QUIC协定没有用四元组的形式来"绑定”连贯，而是通过连贯ID来标记通信的两个端点，客户端和服务器能够各自抉择一组ID来标记本人，因而即便挪动设施的网络变动后，导致IP地址变动了，只有仍保有上下文信息(比方连贯ID、TLS 密钥等)，就能够"无缝"地复用原连贯，打消重连的老本，没有丝毫卡顿感，达到了连贯迁徙的性能。

11. TCP与UDP区别及场景

类型特点性能利用过场景首部字节
TCP面向连贯、牢靠、字节流传输效率慢、所需资源多文件、邮件传输20-60
UDP无连贯、不牢靠、数据报文段传输效率快、所需资源少语音、视频、直播8个字节

基于TCP的协定：HTTP、FTP、SMTP

基于UDP的协定： RIP、DNS、SNMP

12. TCP滑动窗口，拥塞管制

TCP通过：利用数据宰割、对数据包进行编号、校验和、流量管制、拥塞管制、超时重传等措施保证数据的牢靠传输。

拥塞管制目标：为了避免过多的数据注入到网络中，防止网络中的路由器、链路过载。

拥塞管制过程：TCP保护一个拥塞窗口，该窗口随着网络拥塞水平动态变化，通过慢开始、拥塞防止等算法缩小网络拥塞的产生。

13. TCP粘包起因和解决办法

TCP粘包是指：发送方发送的若干包数据到接管方接管时粘成一包

发送方起因：

TCP默认应用Nagle算法（次要作用：缩小网络中报文段的数量）：

收集多个小分组，在一个确认到来时一起发送、导致发送方可能会呈现粘包问题

接管方起因：

TCP将接管到的数据包保留在接管缓存里，如果TCP接管数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

  • 传输层的UDP协定不会产生粘包或者拆包问题

    UDP是基于报文发送的，在UDP首部采纳了16bit来批示UDP数据报文的长度，因而在应用层能很好的将不同的数据报文辨别开，从而防止粘包和拆包的问题。

  • 传输层的TCP协定会产生粘包或者拆包问题

    起因有以下两点：

    1. TCP是基于字节流的，尽管应用层和传输层之间的数据交互是大小不等的数据块，然而TCP把这些数据块仅仅看成一连串无构造的字节流，没有边界；
    2. 在TCP的首部没有示意数据长度的字段，基于下面两点，在应用TCP传输数据时，才有粘包或者拆包景象产生的可能。

解决粘包问题：解决问题的关键在于如何给每个数据包增加边界信息

最实质起因在与接管对等方无奈分辨音讯与音讯之间的边界在哪，通过应用某种计划给出边界，例如：

  • 发送定长包。每个音讯的大小都是一样的，接管方只有累计接收数据，直到数据等于一个定长的数值就将它作为一个音讯。
  • 包尾加上\r\n标记。FTP协定正是这么做的。但问题在于如果数据注释中也含有\r\n，则会误判为音讯的边界。
  • 包头加上包体长度。包头是定长的4个字节，阐明了包体的长度。接管对等方先接管包体长度，根据包体长度来接管包体。

14. TCP、UDP报文格式

TCP报文格式：

源端口号和目标端口号：

用于寻找发端和收端利用过程。这两个值加上IP首部源端IP地址和目标端IP地址惟一确定一个TCP连贯。

序号字段：

序号用来标识从TCP发端向TCP收端发送的数据字节流，它示意在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则 TCP用序号对每个字节进行计数。序号是32 bit的无符号数，序号达到 2^32-1后又从0开始。

当建设一个新的连贯时，SYN标记变1。序号字段蕴含由这个主机抉择的该连贯的初始序号ISN（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个ISN加1，因为SYN标记耗费了一个序号

确认序号：

既然每个传输的字节都被计数，确认序号蕴含发送确认的一端所冀望收到的下一个序号。因而，确认序号该当是上次已胜利收到数据字节序号加 1。只有ACK标记为 1时确认序号字段才无效。发送ACK无需任何代价，因为 32 bit的确认序号字段和A C K标记一样，总是TCP首部的一部分。因而，咱们看到一旦一个连贯建设起来，这个字段总是被设置， ACK标记也总是被设置为1。TCP为应用层提供全双工服务。这象征数据能在两个方向上独立地进行传输。因而，连贯的每一端必须放弃每个方向上的传输数据序号。

首都长度：

首部长度给出首部中 32 bit字的数目。须要这个值是因为任选字段的长度是可变的。这个字段占4 bit，因而TCP最多有6 0字节的首部。然而，没有任选字段，失常的长度是 20字节。

标记字段：在TCP首部中有 6个标记比特，它们中的多个可同时被设置为1。

  • URG紧急指针（u rgent pointer）无效
  • ACK确认序号无效。
  • PSH接管方应该尽快将这个报文段交给应用层。
  • RST重建连贯。
  • SYN同步序号用来发动一个连贯。这个标记和下一个标记将在第 1 8章介绍。
  • FIN发端实现发送工作。

窗口大小：

TCP的流量管制由连贯的每一端通过申明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端冀望接管的字节。窗口大小是一个 16 bit字段，因此窗口大小最大为 65535字节。

测验和：

测验和笼罩了整个的 TCP报文段：TCP首部和TCP数据。这是一个强制性的字段，肯定是由发端计算和存储，并由收端进行验证。

紧急指针：

只有当URG标记置1时紧急指针才无效。紧急指针是一个正的偏移量，和序号字段中的值相加示意紧急数据最初一个字节的序号。TCP的紧急形式是发送端向另一端发送紧急数据的一种形式。

选项：

最常见的可选字段是最长报文大小，又称为 MSS (Maximum Segment Size)。每个连贯方通常都在通信的第一个报文段（为建设连贯而设置 SYN标记的那个段）中指明这个选项。它指明本端所能接管的最大长度的报文段。

UDP报文格式：

端口号：

用来示意发送和承受过程。因为 IP层曾经把I P数据报调配给TCP或 UDP（依据I P首部中协定字段值），因而TCP端口号由TCP来查看，而 UDP端口号由 UDP来查看。TCP端口号与 UDP端口号是互相独立的。

长度：

UDP长度字段指的是 UDP首部和 UDP数据的字节长度。该字段的最小值为 8字节（发送一份0字节的 UDP数据报是 O K）。

测验和：

UDP测验和是一个端到端的测验和。它由发送端计算，而后由接收端验证。其目标是为了发现 UDP首部和数据在发送端到接收端之间产生的任何改变。

IP报文格式：一般的IP首部长为20个字节，除非含有可选项字段。

4位版本：目前协定版本号是4，因而IP有时也称作IPV4.

4位首部长度：

首部长度指的是首部占32bit字的数目，包含任何选项。因为它是一个4比特字段，因而首部长度最长为60个字节。

服务类型（TOS）：

服务类型字段包含一个3bit的优先权字段（当初曾经被疏忽），4bit的TOS子字段和1bit未用位必须置0。4bit的TOS别离代表：最小时延，最大吞吐量，最高可靠性和最小费用。4bit中只能置其中1比特。如果所有4bit均为0，那么就意味着是个别服务。

总长度：

总长度字段是指整个IP数据报的长度，以字节为单位。利用首部长度和总长度字段，就能够晓得IP数据报中数据内容的起始地位和长度。因为该字段长16bit，所以IP数据报最长可达65535字节。当数据报被分片时，该字段的值也随着变动。

标识字段：

标识字段惟一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加1。

生存工夫：

TTL（time-to-live）生存工夫字段设置了数据报能够通过的最多路由器数。它指定了数据报的生存工夫。TTL的初始值由源主机设置（通常为 3 2或6 4），一旦通过一个解决它的路由器，它的值就减去 1。当该字段的值为 0时，数据报就被抛弃，并发送 ICMP 报文告诉源主机。

首部测验和：

首部测验和字段是依据 I P首部计算的测验和码。它不对首部前面的数据进行计算。ICMP、IGMP、UDP和TCP在它们各自的首部中均含有同时笼罩首部和数据测验和码。

以太网报文格式：

目标地址和源地址： 是指网卡的硬件地址（也叫MAC 地址），长度是48 位，是在网卡出厂时固化的。

数据：

以太网帧中的数据长度规定最小46 字节，最大1500 字节，ARP 和RARP 数据包的长度不够46 字节，要在前面补填充位。最大值1500 称为以太网的最大传输单元（MTU），不同的网络类型有不同的MTU，如果一个数据包从以太网路由到拨号链路上，数据包度大于拨号链路的MTU了，则须要对数据包进行分片fragmentation）。ifconfig 命令的输入中也有“MTU:1500”。留神，MTU个概念指数据帧中有效载荷的最大长度，不包含帧首部的长度。

15. TCP协定如何保障牢靠传输机制？

TCP次要提供了测验和、序列号/确认应答、超时重传、滑动窗口、拥塞管制和流量管制等办法实现了可靠性传输。

  • 测验和：通过测验和的形式，接收端能够检测进去数据是否有过错和异样，如果有过错就会间接抛弃TCP段，从新发送。
  • 序列号/确认应答：序列号的作用不仅仅是应答的作用，有了序列号可能将接管到的数据依据序列号排序，并且去掉反复序列号的数据。TCP传输的过程中，每次接管方收到数据后，都会对传输方进行确认应答。也就是发送ACK报文,这个ACK报文当中带有对应的确认序列号，通知发送方，接管到了哪些数据，下一次的数据从哪里发。
  • 超时重传： 超时重传是指发送进来的数据包到接管到确认包之间的工夫，如果超过了这个工夫会被认为是丢包了，须要重传。最大超时工夫是动静计算的。
  • 滑动窗口： 滑动窗口既进步了报文传输的效率，也防止了发送方发送过多的数据而导致接管方无奈失常解决的异样。
  • 拥塞管制： 在数据传输过程中，可能因为网络状态的问题，造成网络拥挤，此时引入拥塞管制机制，在保障TCP可靠性的同时，进步性能。
  • 流量管制： 如果主机A始终向主机B发送数据，不思考主机B的承受能力，则可能导致主机B的承受缓冲区满了而无奈再承受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机B的接收缓冲区状况仍未恶化，则会将大量的工夫节约在重传数据上，升高传送数据的效率。所以引入流量管制机制，主机B通过通知主机A本人接收缓冲区的大小，来使主机A管制发送的数据量。流量管制与TCP协定报头中的窗口大小无关。

16. TCP的滑动窗口?

在进行数据传输时，如果传输的数据比拟大，就须要拆分为多个数据包进行发送。TCP协定须要对数据进行确认后，才能够发送下一个数据包。这样一来，就会在期待确认应答包环节浪费时间。为了防止这种状况，TCP引入了窗口概念。窗口大小指的是不须要期待确认应答包而能够持续发送数据包的最大值。

从下面的图能够看到滑动窗口右边的是已发送并且被确认的分组，滑动窗口左边是还没有轮到的分组。

滑动窗口外面也分为两块，一块是曾经发送然而未被确认的分组，另一块是窗口内期待发送的分组。随着已发送的分组一直被确认，窗口内期待发送的分组也会一直被发送。整个窗口就会往右挪动，让还没轮到的分组进入窗口内。

能够看到滑动窗口起到了一个限流的作用，也就是说以后滑动窗口的大小决定了以后TCP发送包的速率，而滑动窗口的大小取决于拥塞管制窗口和流量管制窗口的两者间的最小值。

17. 具体讲一下拥塞管制? 为何要进行拥塞管制？

A在给B传输数据, A却没有收到B反馈的TCP,A就认为B发送的数据包失落了..进而会从新传输这个失落的数据包。然而理论状况有可能此时有太多主机正在应用信道资源，导致网络拥塞了。重传数据节约了资源，所以要进行拥塞管制。发送发不晓得一次发多少数据适合，所以设置一个拥塞窗口。

TCP拥塞管制原理是通过：慢启动、拥塞防止、快重传、快启动

发送方维持一个叫做拥塞窗口cwnd (congestion window)的状态变量。当cwndssthresh时， 改用拥塞防止算法。

  • 慢开始: 不要一开始就发送大量的数据，由小到大逐步减少拥塞窗口的大小。
  • 拥塞防止: 拥塞防止算法让拥塞窗口迟缓增长，即每通过一个往返工夫RTT就把发送方的拥塞窗口cwnd加1而不是加倍。这样拥塞窗口按线性法则迟缓增长。
  • 快重传: 咱们能够剔除一些不必要的拥塞报文，进步网络吞吐量。比方接管方在收到一个失序的报文段后就立刻收回反复确认，而不要等到本人发送数据时捎带确认。快重传规定:发送方只有一连收到三个反复确认就该当立刻重传对方尚未收到的报文段，而不用持续期待设置的重传计时器工夫到期。
  • 快复原: 次要是配合快重传。当发送方间断收到三个反复确认时，就执行“乘法减小”算法，把ssthresh门限减半(为了预防网络产生拥塞)，但接下来并不执行慢开始算法，因为如果网络呈现拥塞的话就不会收到好几个反复的确认，收到三个反复确认阐明网络情况还能够。

18. TCP拥塞管制4种算法

  • 基于丢包的拥塞管制：将丢包视为呈现拥塞，采取迟缓探测的形式，逐步增大拥塞窗口，当呈现丢包时，将拥塞窗口减小，如Reno、Cubic等。
  • 基于时延的拥塞管制：将时延减少视为呈现拥塞，延时减少时增大拥塞窗口，延时减小时减小拥塞窗口，如Vegas、FastTCP等。
  • 基于链路容量的拥塞管制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时呈现了拥塞，如BBR。
  • 基于学习的拥塞管制：没有特定的拥塞信号，而是借助评估函数，基于训练数据，应用机器学习的办法造成一个控制策略，如Remy。

HTTP协定

1. HTTP协定1.0 1.1 2.0

HTTP1.0：服务器解决实现后立刻断开TCP连贯（无连贯），服务器不跟踪每个客户端也不记录过来的申请（无状态）

HTTP1.1： KeepAlived 长连贯防止了连贯建设和开释的开销；通过Content-Length来判断以后申请数据是否曾经全副承受（有状态）

HTTP2.0：引入二进制数据帧和流的概念，其中帧对数据进行程序标识；因为有了序列，服务器能够并行的传输数据。

无状态的好坏

  • 无状态的益处，因为服务器不会去记忆 HTTP 的状态，所以不须要额定的资源来记录状态信息，这能减 轻服务器的累赘，可能把更多的 CPU 和内存用来对外提供服务。
  • 无状态的害处，既然服务器没有记忆能力，这样每操作一次，都要验证信息。例如登录->增加购物车->下单->结算->领取，这系列操作都要晓得用户的身份才行。但服务器不晓得这些申请是有关联的，每次都要问一遍身份信息。

解决无状态的问题，解法计划有很多种，其中比较简单的形式用 Cookie 和Session技术。

2. HTTP1.0和HTTP1.1的次要区别如下：

  1. 缓存解决：1.1增加更多的缓存控制策略（如：Entity tag，If-Match）
  2. 网络连接的优化：1.1反对断点续传
  3. 谬误状态码的增多：1.1新增了24个谬误状态响应码，丰盛的错误码更加明确各个状态
  4. Host头解决：反对Host头域，不在以IP为申请方标记
  5. 长连贯：缩小了建设和敞开连贯的耗费和提早。

3. HTTP1.1和HTTP2.0的次要区别：

  1. 新的传输格局：2.0应用二进制格局，1.0仍然应用基于文本格式
  2. 多路复用：连贯共享，不同的request能够应用同一个连贯传输（最初依据每个request上的id号组合成失常的申请）
  3. header压缩：因为1.X中header带有大量的信息，并且得反复传输，2.0应用encoder来缩小须要传输的hearder大小
  4. 服务端推送：同google的SPDUY（1.0的一种降级）一样

4. HTTP和 HTTPS的区别：

  1. 最重要的区别就是安全性，HTTP 明文传输，不对数据进行加密安全性较差。HTTPS (HTTP + SSL / TLS)的数据传输过程是加密的，安全性较好。
  2. 证书：应用 HTTPS 协定须要申请 CA 证书，个别收费证书较少，因此须要肯定费用。证书颁发机构如：Symantec、Comodo 、DigiCert 和 GlobalSign 等。
  3. 响应速度：HTTP 页面响应速度比 HTTPS 快，这个很好了解，因为加了一层平安层，建设连贯的过程更简单，也要替换更多的数据，不免影响速度。
  4. 加密：HTTP协定运行在TCP（三次握手）之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都通过加密的。
  5. 端口不同：HTTPS 和 HTTP 应用的是齐全不同的连贯形式，用的端口也不一样，前者是 443，后者是 80。
HTTPHTTPS
默认端口80默认端口443
明文传输、数据未加密、安全性较差传输协定ssl加密、安全性较好
响应速度快，耗费资源少响应速度慢、耗费资源多，须要用到CA证书

5. HTTPS 的毛病：

  1. 在雷同网络环境中，HTTPS 相比 HTTP 无论是响应工夫还是耗电量都有大幅度回升。
  2. HTTPS 的平安是有范畴的，在黑客攻击、服务器劫持等状况下简直起不到作用。
  3. 在现有的证书机制下，中间人攻打仍然有可能产生。
  4. HTTPS 须要更多的服务器资源，也会导致老本的升高。

6. HTTPS链接建设的过程：

  1. 首先客户端先给服务器发送一个申请
  2. 服务器发送一个SSL证书给客户端，内容包含：证书的公布机构、有效期、所有者、签名以及公钥
  3. 客户端对发来的公钥进行真伪校验，校验为真则应用公钥对对称加密算法以及对称密钥进行加密
  4. 服务器端应用私钥进行解密并应用对称密钥加密确认信息发送给客户端
  5. 随后客户端和服务端就应用对称密钥进行信息传输

加密流程按图中的序号分为:

  1. 客户端申请HTTPS网址，而后连贯到server的443端口(HTTPS默认端口，相似于HTTP的80端口)。
  2. 采纳HTTPS协定的服务器必须要有一套数字CA (Certification Authority)证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端本人保留，不可透露。公钥则是附带在证书的信息中，能够公开的。证书自身也附带-一个证书电子签名，这个签名用来验证证书的完整性和真实性，能够避免证书被篡改。
  3. 服务器响应客户端申请，将证书传递给客户端，证书蕴含公钥和大量其余信息，比方证书颁发机构信息，公司信息和证书有效期等。
  4. 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与理论域名不统一，或者证书曾经过期，就会向访问者显示一个正告，由其抉择是否还要持续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。而后客户端还会生成一一个随机码KEY,并应用公钥A将其加密。
  5. 客户端把加密后的随机码KEY发送给服务器，作为前面对称加密的密钥。
  6. 服务器在收到随机码KEY之后会应用私钥B将其解密。通过以上这些步骤，客户端和服务器终于建设了平安连贯，完满解决了对称加密的密钥泄露问题，接下来就能够用对称加密欢快地进行通信了。
  7. 服务器应用密钥(随机码KEY)对数据进行对称加密并发送给客户端，客户端应用雷同的密钥(随机码KEY)解密数据。
  8. 单方应用对称加密欢快地传输所有数据。

7. HTTP常见响应状态码

100：Continue 一一 持续。客户端应持续其申请。

200：OK 一一 申请胜利。一 般用于GET与POST申请。

301：Moved Permanently 一一 永恒重定向。

302：Found 一一 临时重定向。

400：Bad Request 一一 客户端申请的语法错误，服务器无奈了解。申请没有蕴含host头

403：Forbideen 一一 服务器了解申请客户端的申请，然而拒绝执行此申请。禁止客户拜访该资源

404：Not Found 一一 服务器无奈依据客户端的申请找到资源（网页）。资源未找到

500：Internal Server Error 一一 服务器外部谬误，无奈实现申请。

502：Bad Gateway 一一 作为网关或者代理服务器尝试执行申请时，从近程服务器接管到了有效的响应。

8. 状态码301和302的区别是什么?

301为永恒重定向，302为长期重定向

共同点: 301和302状态码都示意重定向，就是说浏览器在拿到服务器返回的这个状态码后会主动跳转到一个新的URL地址，这个地址能够从响应的Location首部中获取(用户看到的成果就是他输出的地址A霎时变成了另一个地址B)。

不同点: 301示意旧地址A的资源曾经被永恒地移除了(这个资源不可拜访了)，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址;302示意旧地址A的资源还在(依然能够拜访)，这个重定向只是长期地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保留旧的网址。SEO中302好于301。

补充，重定向起因:

  1. 网站调整(如扭转网页目录构造);
  2. 网页被移到一个新地址;
  3. 网页扩展名扭转(如利用须要把.php改成.Html或.shtml)。

9. 对称加密算法与非对称加密算法的区别

对称加密算法：

单方持有雷同的密钥，且加密速度快，典型对称加密算法：DES、AES

非对称加密算法：

密钥成对呈现（私钥、公钥），私钥只有本人晓得，不在网络中传输；而公钥能够公开。相比对称加密速度较慢，典型的非对称加密算法有：AES、DSA

10. HTTP申请办法：

办法形容
GET像特定资源发送申请，查问数据，并返回实体
POST向指定资源提交数据进行解决，可能会导致新的资源建设、已有的资源批改
PUT向服务器上传新的内容
HEAD相似GET申请，返回的响应式中没有具体内容，用于获取报头
DELETE申请服务器删除指定标识的资源
OPTIONS能够原来向服务器发送申请来测试服务器的功能性
TRACE回显服务器收到的申请，用于测试和诊断
CONNECTHTTP/1.1协定中预留给可能将连贯改为管道形式的代理服务器

11. Get和Post申请区别

GETPOST
HTTP标准GET用于信息获取批改服务器上的资源的申请
可见性数据在URL中对所有人可见数据不会显示在URL中
安全性与post相比，get的安全性较差，因为所发送的数据是URL的一部分平安，因为参数不会被保留在浏览器历史或web服务器日志中
数据长度受限制，最长2kb无限度
编码类型application/x-www-form-urlencodedmultipart/form-data
缓存能被缓存不能被缓存

12. GET 和 POST 办法都是平安和幂等的吗？

先阐明下平安和幂等的概念：

  • 在 DSA协定里，所谓的「平安」是指申请办法不会「毁坏」服务器上的资源。
  • 所谓的「幂等」，意思是屡次执行雷同的操作，后果都是「雷同」的。

那么很显著 GET 办法就是平安且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据 都是平安的，且每次的后果都是雷同的。

POST 因为是「新增或提交数据」的操作，会批改服务器上的资源，所以是不平安的，且屡次提交数据 就会创立多个资源，所以不是幂等的。

13. 重定向和转发区别

转发是服务器行为,重定向是客户端行为

重定向：redirect：

地址栏发生变化

重定向能够拜访其余站点（服务器）的资源

重定向是两次申请。不能应用request对象来共享数据

转发：forward：

转发地址栏门路不变

转发只能拜访以后服务器下的资源

转发是一次申请，能够应用request对象共享数据

14. Cookie和Session区别

Cookie 和 Session都是用来跟踪浏览器用户身份的会话形式，但两者有所区别：

Cookie 数据保留在客户端(浏览器端)，Session 数据保留在服务器端。

cookie不是很平安，他人能够剖析寄存在本地的Cookie并进行坑骗,思考到平安该当应用session。

Cookie ⼀般⽤来保留⽤户信息，Session 的次要作⽤就是通过服务端记录⽤户的状态

15. 浏览器输出URL过程

过程：DNS解析、TCP连贯、发送HTTP申请、服务器解决申请并返回HTTP报文、浏览器渲染、完结

  1. 域名解析(域名www.baidu.com变为IP地址)。浏览器搜寻本人的DNS缓存(保护一张域名与IP的对应表);
    1. 若没有，则搜寻操作系统的DNS缓存(保护一张域名与IP的对应表) ;
    2. 若没有，则搜寻操作系统的hosts文件(保护一张域名与IP的对应表)。
    3. 若都没有，则找TCP/IP参数中设置的首选dns服务器，即本地DNS服务器(递归查问)，本地域名服务器查问本人的DNS缓存，如果没有，则进行迭代查问。将本地dns服务器将IP返回给操作系统，同时缓存IP。
  3. 发动TCP的三次握手，建设TCP连贯。浏览器会以一个随机端口(1024-65535) 向服务端的web程序80端口发动TCP的连贯。
  4. 建设TCP连贯后发动HTTP申请。
  5. 服务器响应HTTP申请，客户端失去html代码。服务器web应用程序收到HTTP申请后，就开始解决申请，解决之后就返回给浏览器html文件。
  6. 浏览器解析html代码，并申请html中的资源。
  7. 浏览器对页面进行渲染，并出现给用户。

如何查看 TCP 的连贯状态？TCP 的连贯状态查看，在 Linux 能够通过 netstat -napt 命令查看。

16. DNS协定是TCP还是UDP?

  • DNS占用53号端口，同时应用TCP和UDP协定。那么DNS在什么状况下应用这两种协定？

    DNS在区域传输的时候应用TCP协定，其余时候应用UDP协定。

    • 客户端向DNS服务器查问域名，个别返回的内容都不超过512字节，用UDP传输即可。不必通过TCP三次握手，这样DNS服务器负载更低，响应更快。尽管从实践上说，客户端也能够指定向DNS服务器查问的时候应用TCP，但事实上，很多DNS服务器进行配置的时候，仅反对UDP查问包。
    • 辅域名服务器会定时（个别3小时）向主域名服务器进行查问以便理解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送应用TCP而不是UDP，因为数据同步传送的数据量比一个申请应答的数据量要多得多。
    • TCP是一种牢靠连贯，保障了数据的准确性。
    • DNS区域传输的时候应用TCP协定：
    • 域名解析时应用UDP协定：

17. ARP协定如何找到对应IP地址和mac的映射的

简略地说，ARP 是借助 ARP 申请与 ARP 响应两种类型的包确定 MAC 地址的。

  • 主机会通过播送发送 ARP 申请，这个包中蕴含了想要晓得的 MAC 地址的主机 IP 地址。
  • 当同个链路中的所有设施收到 ARP 申请时，会去拆开 ARP 申请包里的内容，如果 ARP 申请包中 的指标 IP 地址与本人的 IP 地址统一，那么这个设施就将本人的 MAC 地址塞入 ARP 响应包返回 给主机。

操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次间接从缓存中找到对应 IP 地 址的 MAC 地址。不过， MAC 地址的缓存是有肯定期限的，超过这个期限，缓存的内容将被革除

18. RARP 协定你晓得是什么吗？

ARP 协定是已知 IP 地址求 MAC 地址，那 RARP 协定正好相同，它是已知 MAC地址求 IP 地址。例如 将打印机服务器等小型嵌入式设施接入到网络时就常常会用失去。

通常这须要架设一台 RARP 服务器，在这个服务器上注册设施的 MAC 地址及其 IP 地址。而后再将 这个设施接入到网络，接着：

  • 该设施会发送一条「我的 MAC 地址是XXXX，请通知我，我的IP地址应该是什么」的申请信息。
  • RARP 服务器接到这个音讯后返回「 MAC地址为 XXXX 的设施，IP地址为 XXXX」的信息给这个 设施。

最初，设施就依据从 RARP 服务器所收到的应答信息设置本人的 IP 地址

19. 什么是DDos攻打?

DDos全称Distributed Denial of Service，分布式拒绝服务攻打。最根本的DOS攻打过程如下:

  1. 客户端向服务端发送申请链接数据包。
  2. 服务端向客户端发送确认数据包。
  3. 客户端不向服务端发送确认数据包，服务器始终期待来自客户端的确认

DDos则是采纳分布式的办法，通过在网络上霸占多台“肉鸡”，用多台计算机发动攻打。

DDos攻打当初根本没啥作用了，因为服务器的性能都很好，而且是多台服务器独特作用，1V1的模式黑客无奈占上风。对于DDos攻打，预防办法有:

  • 缩小SYN timeout工夫。在握手的第三步，服务器会期待30秒-120秒的工夫，缩小这个等待时间就能开释更多的资源。
  • 限度同时关上的SYN半连贯数目。

20. 什么是XSS攻打?

XSS也称cross-sitescripting,跨站脚本。这种攻打是因为服务器将攻击者存储的数据原原本本地显示给其余用户所致的。比方一个存在XSS破绽的论坛，用户发帖时就能够引入带有< script>标签的代码，导致恶意代码的执行。

预防措施有:

  • 前端：过滤。
  • 后端：本义，比方go自带的处理器就具备本义性能。

21. SQL注入是什么，如何防止SQL注入?

SQL注入就是在用户输出的字符串中退出SQL语句，如果在设计不良的程序中疏忽了查看，那么这些注入进去的SQL语句就会被数据库服务器误认为是失常的SQL语句而运行，攻击者就能够执行计划外的命令或拜访未被受权的数据。

SQL注入的原理次要有以下4点：

  1. 歹意拼接查问
  2. 利用正文执行非法命令
  3. 传入非法参数
  4. 增加额定条件

防止SQL注入的一些办法：

  1. 参数校验：在一些不该有特殊字符的参数中提前进行特殊字符校验即可。
  2. 限度数据库权限，给用户提供仅仅可能满足其工作的最低权限。
  3. 提供参数化查问接口，不要间接应用原生SQL。
  4. SQL预编译

在晓得了SQL注入的原理之后，咱们同样也理解到MySQL有预编译的性能，指的是在服务器启动时，MySQL Client把SQL语句的模板（变量采纳占位符进行占位）发送给MySQL服务器，MySQL服务器对SQL语句的模板进行编译，编译之后依据语句的优化剖析对相应的索引进行优化，在最终绑定参数时把相应的参数传送给MySQL服务器，间接进行执行，节俭了SQL查问工夫，以及MySQL服务器的资源，达到一次编译、屡次执行的目标，除此之外，还能够避免SQL注入。

具体是怎么避免SQL注入的呢？实际上当将绑定的参数传到MySQL服务器，MySQL服务器对参数进行编译，即填充到相应的占位符的过程中，做了本义操作。咱们罕用的JDBC就有预编译性能，不仅晋升性能，而且避免SQL注入。

22. 网络编程socket，客户端和服务端通信过程，别离调用了哪些函数，作用是什么

  • 服务器端程序：
    1. 创立一个socket，用函数socket()
    2. 绑定IP地址、端口等信息到socket上，用函数bind()
    3. 设置容许的最大连接数，用函数listen()
    4. 接管客户端上来的连贯，用函数accept()
    5. 收发数据，用函数send()和recv()，或者read()和write()
    6. 敞开网络连接
  • 客户端程序：
    1. 创立一个socket，用函数socket()
    2. 设置要连贯的对方的IP地址和端口等属性
    3. 连贯服务器，用函数connect()
    4. 收发数据，用函数send()和recv()，或read()和write()
    5. 敞开网络连接

23. 负载平衡算法有哪些?

nginx负载平衡的三种形式次要是轮询模式、weight权重模式、ip_hash。

当一台服务器的单位工夫内的访问量越大时，服务器压力就越大，大到超过本身承受能力时，服务器就会解体。为了防止服务器解体，让用户有更好的体验，咱们通过负载平衡的形式来分担服务器压力。

  1. 轮询模式（默认）每个申请按工夫程序逐个调配到不同的后端服务器，如果后端服务器down掉，能主动剔除。适宜服务器配置相当，无状态且短平快的服务应用。也实用于图片服务器集群和纯动态页面服务器集群。
  2. weight权重模式这种形式比拟灵便，当后端服务器性能存在差别的时候，通过配置权重，能够让服务器的性能失去充分发挥，无效利用资源。weight和拜访比率成正比，用于后端服务器性能不均的状况。权重越高，在被拜访的概率越大

  3. ip_hash上述weight权重模式形式存在一个问题，在负载平衡零碎中，如果用户在某台服务器上登录了，那么该用户第二次申请的时候，因为咱们是负载平衡零碎，每次申请都会从新定位到服务器集群中的某一个，那么曾经登录某一个服务器的用户再从新定位到另一个服务器，其登录信息将会失落，这样显然是不妥的。

    能够采纳ip_hash指令解决这个问题，如果客户曾经拜访了某个服务器，当用户再次拜访时，会将该申请通过哈希算法，主动定位到该服务器。每个申请按拜访IP的hash后果调配，这样每个访客固定拜访一个后端服务器，能够解决session不能跨服务器的问题。