带你了解前端工程师需要知道的计网知识

概述

计算机网络是通信技术与计算机技术结合的产物，也就是说计算机网络就是为了解决计算机与计算机之间通讯的问题。

在现实世界中，我们用信息来形容交换的内容，在计算机世界里，我们用「数据」这个词来代替。

互联网是如何运作的

十分钟了解一下-> www.bilibili.com/video/BV1Rz…

网络编程

本质：多台计算机之间的数据交换

现在的网络编程基本上就是就是基于请求/响应方式的，也就是一个设备发送请求给另外一个，然后接受另一个设备的反馈。

发起连接程序，发送第一次请求的程序，称作客户端。

等待其他程序连接的程序，称作服务器。

客户端程序可以在需要的时候启动，而服务器为了能够时刻响应连接，需要一直启动。

网络编程中的两个主要的问题

找主机：如何准确定位网络上一台或多台主机
数据传输：找到主机后如何高效可靠的进行数据传输

在TCP/IP协议中IP层主要负责网络主机的定位，数据传输的路由，由IP地址可以唯一地确定Internet上的一台主机。

而TCP层则提供面向应用的可靠的（TCP）或非可靠（UDP）的数据传输机制。

网络协议

在计算机网络要做到井井有条的交换数据，就必须遵守一些实现约定好的规则，比如交换数据的格式、是否需要发送一个应答消息。这些规则被称为网络协议。

为什么要对网络协议分层

简化问题难度和复杂度。由于各层之间独立，我们可以分割大问题为小问题。
灵活性好。当其中一层的技术变化时，只要层间接口关系保持不变，其他层不受影响。
易于实现和维护。
促进标准化工作。分开后，每层功能可以相对简单地被描述。

计算机网络体系结构

OSI参考模型

OSI，开放式系统互联。定义了网络互连的七层框架（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层）

TCP/IP参考模型

四层协议

应用层

最靠近用户的一层，是为计算机用户提供应用接口，也为用户提供各种网络服务。常见的网络服务协议有：HTTP、HTTPS、FTP、TELNET等。
传输层

建立了主机端到端的连接，传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，包括处理差错控制和流量控制等问题。该层向高层屏蔽了下层数据通信的细节，使高层用户看到的只是两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。常说的TCP,UDP就是在这一层，端口号就是这里的“端”。
网络层

本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。就是常说的IP层，IP协议是Internet的基础。
数据链路层

通过一些规程或协议来控制这些数据的传输，以保证被传输数据的正确性。实现这些规程或协议的硬件和软件加到物理线路，这样就构成了数据链路。

TCP和UDP

TCP/IP即传输控制/网络协议，是面向连接的协议，发送数据前要先建立连接，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达。

UDP是属于TCP/IP协议族中的一种。是无连接的协议，发送数据前不需要建立连接，是不可靠的协议。因为不需要建立连接所以可以在网络上以任何可能的路径传输，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能保证的。

TCP通信类似于打电话，接通了，确认身份后再进行通信。

UDP通信类似于学校广播，靠着广播播报直接进行通信。

TCP首部格式

序号

用于对字节流进行编号。
确认号

期待收到的下一个报文段的序号。
数据偏移

指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
确认ACK

当ACK=1时确认字段有效，否则无效。TCP规定，在连接建立后所有的报文段都必须把ACK置为1。
同步SYN

在连接建立时用来同步序号。
终止FIN

用来释放一个连接，当FIN=1时，表示此报文段的发送方数据已经发送完毕，并要求释放连接。
窗口

窗口值是接收方让发送方设置其发送窗口的依据，因为接收方的数据缓存空间是有限的，所有要有这个限制。

UDP首部格式

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

区别

TCP是面向连接的协议，发送数据前要先建立连接，TCP提供可靠的服务，也就是说，通过TCP连接传输的数据不会丢失，没有重复，并且按顺序到达;

UDP是无连接的协议，发送数据前不需要建立连接，没有可靠性;
TCP只支持点对点通信，UDP支持一对一，一对多，多对一，多对多。
TCP是面向字节流的，UDP是面向报文的；面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。
TCP首部开销（20字节）比UDP首部开销（8字节）要大。
UDP的主机不需要维持复杂的连接状态表。

应用场景

对某些实时性要求较高的选择UDP，比如游戏，媒体通信，实时直播，即使出现传播错误也可以容忍。其他大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失的情况。

TCP三次握手

客户端向服务器发送SYN
服务端返回SYN、ACK
客户端发送ACK

第一次握手:Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态;
第二次握手:Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK 置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端;进入SYN_RCVD状态;
第三次握手:客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器;进入 ESTABLISHED状态;服务器检查ACK为1和acknowledge number为序列号+1之后，也进入 ESTABLISHED状态;完成三次握手，连接建立。

目的是建立可靠的通信通道，双方确认自己与对方的发送和接收功能正常。

建立连接可以进行两次握手吗？

不可以。

因为可能会出现已经失效的连接请求报文段又传到了服务器端。
两次握手也无法保证客户端正确接收第二次握手的报文（Server无法确认Client是否收到），也无法保证Client和Server之间成功互换初始序列号。

建立连接可以进行四次握手吗？

可以但没必要。因为会降低传输的速率。

第三次握手中如果客户端的ACK未送达服务器，会怎样？

Server端：

由于server没有收到ACK确认，因此会每隔3秒重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。
Client端：
- 在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1，此时服务器收到数据后会读取ACK number，进入ESTABLISH状态。
- 在Server进入CLOSED状态后，如果Client向服务器发送数据，服务器会以RST包应答。

如果建立了连接，但客户端出现了故障，怎么办？

服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常设置为两个小时，若两个小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次，若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP四次挥手

第一次挥手:Client将FIN置为1，发送一个序列号seq给Server;进入FIN_WAIT_1状态;
第二次挥手:Server收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1; 进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。
第三次挥手:Server将FIN置1，发送一个序列号给Client;进入LAST_ACK状态;
第四次挥手:Client收到服务器的FIN后，进入TIME_WAIT状态;接着将ACK置1，发送一个 acknowledge number=序列号+1给服务器;服务器收到后，确认acknowledge number后，变为 CLOSED状态，不再向客户端发送数据。客户端等待2*MSL(报文段最长寿命)时间后，也进入 CLOSED状态。完成四次挥手。

四次挥手断开连接是确认了传输的数据已经传输完了。

为什么不能把服务器发送的ACK和FIN合并起来，编程变成三次挥手？（CLOSE_WAIT状态意义是什么）

因为服务器接收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示已经收到了断开连接的请求，等到数据发送完成之后再发FIN，断开服务器到客户端的数据传送。

客户端TIME_WAIT状态的意义是什么

第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果Sever没有收到ACK，就会重发FIN，如果Client在2*MSL的事件收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。

MSL，一个片段在网络中最大的存活时间。2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经成功被接受，则结束连接。

TCP如何保证传输的可靠性

校验和

计算方式：在数据传输的过程中，将发送的数据都当做一个16位的整数，将这些整数都加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。

发送方：在发送数据之前计算校验和，并进行校验和的填充。

接收方：收到数据后，对数据以相同的方式进行计算，求出校验和后和发送方的进行比对。

如果接收方与发送方校验和不一致，数据传输一定发生错误。如果接收方与发送方校验和一致，数据不一定传输成功。
序列号和确认应答

序列号：TCP传输时将每个字节的数据都进行了编号，这就是序列号。接收方可以根据接收数据的序列号进行排序，并且去掉重复序列号的数据。

确认应答：在TCP传输过程中，每次接收方收到数据后，都会对传输方进行确认应答，也就是发送ACK报文。

ACK报文：可以告诉发送方，接收方接收到了哪些数据，下一次的数据从哪里开始发。
超时重传

原因：在进行TCP传输的过程中，由于序列号和确认应答的机制，当发送方发送一部分数据后，都会去等待接收方发送ACK报文，并解析ACK报文，判断数据是否发送成功。如果发送方发送完数据之后，迟迟没有等到接收方的ACK报文，这时候就引入了超时重传机制。

发送方没有收到响应的ACK报文原因：

1、接收方由于网络原因没有接收到发送方的数据。

2、接收方接收到了响应的数据，但是发送的ACK报文响应由于网络原因丢包了。

超时重传机制：在发送方发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么对刚才发送的数据进行重发。如果是第一个原因，接收方收到二次重发的数据后，进行ACK应答，如果是第二个原因，接收方发现接收的数据已存在（通过序列号），那么直接丢弃这个包，发送ACK应答。

累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。
流量控制
拥塞控制

TCP滑动窗口

产生原因：TCP是以一个段为单位进行数据的传输的，每发送一个段，就会等待对端主机的针对这个段的确认应答信号ACK，但这样的传输方式的缺点也很明显，就是：当数据包的往返时间越长，通信性能越低。

滑动窗口机制中确认应答包不再以每个段为单位进行确认，而是以更大的单位进行确认，这样发送方发送一个段后不用一直等待接收方的确认应答信号，而是继续发送。

发送方和接收方各有一个窗口，接收方通过TCP报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其他信息设置自己的窗口大小。

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

当在前面还有字节未接收但收到后面字节的情况下，接收窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

TCP流量控制

接收端在收到数据之后，对其进行处理。如果发送端发送速度太快，导致接收端的接收缓冲区很快的填充满了。此时如果发送端仍旧发送数据，那么接下来发送的数据都会丢包，继而导致丢包的一系列连锁的反应。

TCP根据接收端对数据处理的能力，决定发送端的发送速度，这个机制就是流量控制。

在TCP协议的报头信息当中，有一个16位字段的窗口大小，窗口大小的内容实际上是接收端接收数据缓冲区的剩余大小。这个数字越大，证明接收端接收缓冲区的剩余空间越大，网络的吞吐量越大。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。而发送方根据ACK报文里的窗口大小的值的改变进而改变自己的发送速度。如果接收到窗口大小的值为0，那么发送方将停止发送数据。并定期的向接收端发送窗口探测数据段，让接收端把窗口大小告诉发送端。

注：16位的窗口大小最大能表示65535个字节（64K），但是TCP的窗口大小最大并不是64K。在TCP首部中40个字节的选项中还包含了一个窗口扩大因子M，实际的窗口大小就是16为窗口字段的值左移M位。每移一位，扩大两倍。

TCP拥塞控制

TCP传输的过程中，发送端开始发送数据的时候，如果刚开始就发送大量的数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中在扔出大量数据，那么这个拥堵就会加剧。拥堵的加剧就会产生大量的丢包，就对大量的超时重传，严重影响传输。

因此出现拥塞的时候，应当控制发送方的速率。

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

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

发送最初执行慢开始（在发送数据时，先发送少量的数据探路，探清当前的网络状况如何，再决定多大的速度进行传输），令cwnd=1，发送方只能发送一个报文段。

收到确认后，将cwnd加倍，因此之后发送方能够发送的报文数量为2、4、8...

慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍，设置一个拥塞窗口的阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性的增长。设置一个开始门限ssthresh，当cwnd>=ssthresh时，进入拥塞避免，每个轮次cwnd加1.

如果出现了超时，则令ssthresh=cwnd/2，重新执行慢开始，cwnd=1。

在接收方，每次接收到报文段后应该对最后一个已收到的有序的报文段进行确认。

在发送方，如果收到了三个重复确认，就知道了下一个报文段丢失了，此时执行快重传，立刻重传下一个报文段。

但是这种情况只是丢失了个别报文段，而不是网络拥塞。此时执行快恢复，令ssthresh = cwnd/2，cwnd=ssthresh，注意到此时直接进入了拥塞避免。

在浏览器中，一个页面从输入URL到加载完成的过程

域名解析（DNS协议，将符合人类记忆习惯的域名解析为计算机可理解的服务器的IP地址)
建立TCP连接，浏览器与服务器进行3次握手建立连接
浏览器发起http请求，发送请求数据
tcp将http请求报文切割为报文段，并在各个报文上打上标记序号以及端口号，将每个报文段可靠地传给网络层
ip协议在网络层通过ip地址找到mac地址（ARP协议，解析地址，根据通信方的ip地址反查出对应的MAC地址），在各个路由中间进行路由中转传送到数据链路层
服务器端在数据链路层收到数据，按数据链路层→网络层→传输层→应用层顺序逐层发送数据，期间，之前加在数据报上的报头信息被层层解析丢弃。
服务器响应http请求，发送响应数据。重复上述步骤并向服务器请求这些资源...
浏览器收到响应数据，解析收到的html、css和js等文件，并渲染页面。

Socket

网络上的两个程序通过一个双向的通讯连接实现数据的交换，这个双向链路的一端称为一个Socket。Socket通常用来实现客户方和服务方的连接。Socket是TCP/IP协议的一个十分流行的编程界面，一个Socket由一个IP地址和一个端口号唯一确定。

Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。

HTTP

HTTP协议是对客户端和服务器端之间实现可靠性的传输文字、图片、音频、视频等超文本数据的规范，简称为“超文本传输协议”。属于应用层。

Web service = http协议 + XML

Rest = http协议 + json

各种API也一般是用http协议 + XML/json来实现的。

Socket和HTTP的区别和应用场景

Socket连接是长连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉。

适用场景：网络游戏，银行持续交互，直播，在线视频。
HTTP连接是短连接，即客户端和服务端发送一次请求，服务器端响应后连接即会断开等待下一次连接。

适用场景：公司OA服务，互联网服务，电商，办公等。

HTTP和HTTPS的区别

其实HTTPS就是从HTTP加上加密处理（一般是SSL安全通信线路）+ 认证 + 完整性保护

区别

Https需要拿到CA证书（数字证书），需要资金。
端口不一样，http是80，https是443
信息传输不一样。http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式（http的连接很简单，无状态；https协议是由ssl和http协议构建的可进行加密传输，身份认证的网络协议，比http协议安全）

HTTPS的安全认证

1，https是基于tcp协议的，客户端先会和服务端发起链接建立

2，接着服务端会把它的证书返回给客户端，证书里面包括公钥S.pub、颁发机构和有效期等信息

3，拿到的证书可以通过浏览器内置的根证书（内含C.pub）验证其合法性

4，客户端生成随机的对称加密秘钥Z，通过服务端的公钥S.pub加密发给服务端

5，客户端和服务端通过对称秘钥Z加密数据来进行http通信

1-服务器会预先生成非对称加密密钥，私钥S.pri自己保留；而公钥S.pub则发给CA机构进行签名认证

2-CA也会预先生成一非对称加密密钥，其私钥C.pri用来对服务器的公钥S.pub进行签名生成CA证书

3-CA机构会把签名生成的CA证书返回给服务器，也就是刚才服务端给客户端那个证书

4-因为CA(证书颁发机构)比较权威，所以很多浏览器会内置包含它公钥(C.pub)的证书，称之为根证书。然后可以使用根证书来验证其颁发证书的合法性了。

细节

首先，服务器把他的公钥和个人信息用Hash算法生成一个消息摘要，这个Hash算法有个好的特点就是只要输入的数据有一点点变化，那么生成的消息摘要就会发生巨变。这样就可以防止别人修改原始的内容。然后再将这个消息摘要通过认证中心(CA)的私钥进行加密，形成数字签名。

接着再把数字签名和原始信息(主机B得公钥和信息)合并，形成一个新的东西，叫做数字证书。

当服务器把这个数字证书发给客户端时，客户端用相同的Hash算法对原始信息生成消息摘要，再用CA的公钥对数字签名进行解密，得到CA创建消息摘要，然后进行对比，看有没有改变。如果一样，说明公钥没人改，也就是说此时的公钥就是服务器的公钥。

CA证书

CA证书是为了确保服务端的公钥是准确无误，没被修改过的。

证书通常包含这些内容(1) 服务端的公钥；(2) 证书发行者(CA)对证书的数字签名；(3) 证书所用的签名算法；(4) 证书发布机构、有效期、所有者的信息等其他信息

HTTP请求信息和相应信息的格式

请求：

请求行
请求头信息 key:value
请求主体信息(可以没有)

请求行

分三部分：请求方法，请求路径，所用的协议

请求方法

GET/POST/HEAD/PUT/DELETE/TRACE/OPTIONS

注意：这些请求方法虽然是http协议里规定的，但web server未必允许或支持这些方法

GET方法和POST方法的区别

GET重点在于从服务器上获取资源，POST重点在向服务器发送数据。
GET传输的数据量小，因为受URL长度限制，但效率较高。POST可以传输大量数据，所以上传文件时只能用POST方式。
GET是不安全的，因为GET请求发送数据是在URL上的，是可见的，可能会泄漏私密信息，如密码等；POST将传输数据放在请求头部，是比较安全的。

post常用的content-type

application/x-www-form-urlencoded 表单
multipart/form-data 文件
application/json json数据

请求主体

头信息结束后，有一个空行，头信息和主体信息，需要这个空行作区分，即使没有主体信息，空行也不能少。

响应：

响应行：协议版本、状态码、状态文字
响应头信息 key:value
响应主体信息（可无）

HEAD和GET基本一致，只是不需要返回内容

TRACE：用了代理上网，你想看看代理有没有修改你的http请求

OPTIONS:返回服务器允许请求的方法

状态码和状态文字

状态码表示客户端HTTP请求的返回结果，标识服务器处理是否正常、表明请求出现的错误等，是用来反映服务器响应情况的。

状态文字是用来描述状态码的，便于人观察。

常见：

200 服务器成功返回网页
301/302 永久/临时重定向
304 Not Modified 未修改
307 重定向中保持原有的数据请求
404 请求的网页不存在
503 服务器暂时不可用
500 服务器内部错误

缓存控制

缓存的优缺点

优点
- 减少了不必要的数据传输，节省带宽
- 减少了服务器的负担，提升网站性能
- 加快了客户端加载网页的速度
缺点如果资源有更改客户端不及时更新会导致用户获取消息滞后。

缓存

强缓存（服务端设置）当浏览器去请求某个文件的时候，服务端就在respone header里面对该文件做了缓存配置。缓存的时间、缓存类型都由服务端控制，客户端每次请求资源时都会看是否过期，只有在过期才会去询问服务器。（不会向服务器发送请求,直接从缓存中读取资源）
expires(http/1.0,时间格式GMT) 表示响应头里的过期时间,浏览器再次加载资源时如果在时间之内就命中缓存。
cache-control(http/1.1,单位秒)
- max-age(表示缓存内容在 xx秒后消失)
- no-cache(要根据协商缓存是否需要缓存客户端)
- no-store(所有内容都不会被缓存)
- public(所有内容都将被缓存包括客户端和代理服务器)
- private(所有内容只有客户端可以缓存)
- s-maxage(只用于共享缓存和max-age效果一样,只是max-age 用于普通缓存)
协商缓存（客户端设置，服务端判断）当协商缓存生效时,返回304和Not Modified 它指的是强制缓存失效后,浏览器携带缓存标示向服务器发起请求,由服务器决定是否需要使用缓存。
Last-Modified和 If-Modified-Since
- Last-Modifeds是服务器返回资源同时在header添加的,表示这个资源在服务器上最后修改时间,浏览器接受后缓存文件和header。
- 浏览器下次请求时，检测是否有Last-Modified字段,如果存在则在请求头添加 If-modified-Since该字段值就是上次服务器返回的值。
- 如果没有变化则返回304直接从缓存中读取，否则返回新资源。
ETag和If-None-Match
- Etag是上一次加载资源时,服务器返回的。它的作用是唯一用来标示资源是否有变化。
- 浏览器下次请求时将ETag值传入If-None-Match中,服务端匹配传入的值与上次是否一致，如果一致返回304否则返回新资源和新的ETag。
本地存储
- localStorage 在前端设置,可以减少数据请求，长期存储。
- sessionStorage 在前端设置，只存在当前会话中，重新打开浏览器则数据消失。
- cookie 在后端设置,保存在客户端本地文件,通过set-cookie设置且Cookie的内容自动在请求的时候被传递到服务器。
- indexDB 为浏览器提供本地数据库,提供查找接口,还能建立索引。

HTTP工作原理

首先http请求服务端生成证书，客户端对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥（RSA加密）等进行校验。
客户端如果校验通过后，就根据证书的公钥的有效，生成随机数，随机数使用公钥进行加密（RSA加密）。
消息体产生后，对它的摘要进行MD5（或者SHA1）算法加密，此时就得到了RSA签名。
发送给服务端，此时只有服务端（RSA私钥）能解密。
解密得到的随机数，再用AES加密，作为密钥（此时的密钥只有客户端和服务器知道）。

一次完整的HTTP请求所经历的几个步骤

HTTP通信机制是在一次完整的HTTP通信过程中，Web浏览器和Web服务器之间将完成以下7个步骤：

建立TCP连接（三次握手）
Web浏览器向Web服务器发送请求行

一旦建立连接，浏览器会向服务器发送请求命令。

如GET /test/hello.jsp HTTP/1.1
Web浏览器发送请求头

浏览器发送其请求命令后，还要以头信息的形式向服务器发送一些别的信息，之后浏览器发送一行空白行来通知服务器，它已经结束了该头信息的发送。
Web服务器应答

客户端向服务器发出请求后，服务器会回送应答，HTTP/1.1 200 OK，即协议版本号和应答状态码和状态文字。
Web服务器发送应答头

服务器以头信息的形式向服务器发送一些别的信息。
Web服务器向Web浏览器发送数据

Web服务器向浏览器发送头信息之后，会发送一个空白行表示头信息发送完毕，接着，它以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。
Web服务器关闭TCP连接

HTTP版本的对比

HTTP1.0特性

早先1.0的HTTP版本，是一种无状态、无连接的应用层协议。

HTTP1.0规定浏览器和服务器保持短暂的连接，浏览器的每次请求都需要与服务器建立一个 TCP连接，服务器处理完成后立即断开TCP连接(无连接)，服务器不跟踪每个客户端也不记录过去的请求(无状态)。

HTTP1.1相比HTTP1.0提高了什么性能？

长连接只要任意一端没有明确提出断开连接，则保持TCP连接状态，可以发送多次HTTP请求。
管道网络传输客户端可以同时发出多个HTTP请求，而不用一个个等待响应。

HTTP/1.1 的性能瓶颈

请求/响应头部未经压缩就发送，首部信息越多延迟越大，只能压缩body部分。
发送冗长的首部，每次互相发送相同的首部造成的浪费较多。
服务器是按请求的顺序响应的，当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这就是队头阻塞。
没有请求优先级控制。
请求只能从客户端开始，服务器只能被动响应。

针对 HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？

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

二进制分帧 (采用二进制格式的编码将其头信息和数据体封装，对计算机友好)
首部压缩 (设置了专门的首部压缩设计的HPACK算法。)
流量控制 (设置了接收某个数据流的多少字节一些流量控制)
多路复用！ (可以在共享TCP链接的基础上同时发送请求和响应)
请求优先级 (可以通过优化这些帧的交错和传输顺序进一步优化性能)
服务器推送 (服务器可以对一个客户端请求发送多个响应。服务器向客户端推送资源无需客户端明确的请求。(重大更新))

HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？

HTTP2主要问题在于：多个HTTP请求在复用一个TCP连接，下层的TCP协议是不知道有多少个HTTP请求的。

一旦发生丢包现象，就会触发TCP的重传机制，这样在一个TCP连接中所有的HTTP请求都必须等待这个丢了的包被重传回来。

HTTP3把HTTP下层的TCP协议改成了UDP。

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

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

QUIC有自己的一套机制可以保证传输的可靠性。当某个流发生丢包时，只会阻塞这个流，其他流不会收到影响。
TL3升级成了最近的1.3版本，头部压缩算法也升级为QPack。
HTTPS建立一个连接需要花费六次交互，显示建立三次握手，然后是TLS1.3的三次握手。QUIC直接把以往的TCP和TLS/1.3交互合并成了三次，减少了交互次数。

QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

什么是对称加密与非对称加密

对称加密：加密和解密使用同一个密钥，存在问题是密钥发送问题，即如何安全地将密钥发给对方。
非对称加密：使用一对非对称密钥，即公钥和私钥。公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性。但是和对成加密比起来，非常的慢。

cookie和session对于HTTP的作用

HTTP协议本身是无状态的，无法判断用户身份，所以需要cookie或者session。

cookie

cookie是Web服务器保存在用户浏览器上的文件（key-value格式），可以包含用户相关的信息。客户端向服务器发起请求，就提取浏览器中的用户信息由http发送给服务器。

session

session是浏览器和服务器会话过程中，服务器会分配一块存储空间给session。

服务器默认为客户浏览器的cookie中设置sessionid，服务器根据传输cookie中的sessionid获取出会话中存储的信息，然后确定会话的身份信息。

cookie和session区别

cookie数据存放在客户端上，安全性较差，session数据放在服务器上，安全性相对较高。
单个cookie保存的数据不能超过4K，session无此限制信息后，使用自己的私钥进行解密。由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，非常的慢。
存储内容不同。cookie只能保存字符串类型，以文本的方式；session通过类似与Hashtable的数据结构来保存，能支持任何类型的对象(session中可含有多个对象）

cookie，localStorage， sessionStorage三者区别

cookie始终在同源的http请求中携带，即使不需要，cookie在浏览器和服务器中来回传递。而localStorage和sessionStora保存在客户端，不与服务器进行交互通信。
存储大小不同。cookie为4kb左右；localStorage， sessionStorage可以达到5M。
localStorage， sessionStorage有现成的API， cookie需要程序员手动封装。
数据有效期不同，sessionStorage仅在同源窗口中有效，关闭窗口就消失了，cookie可以设置过期时间，localStorage长期有效。

IP协议

ipv4与ipv6

先占个位= =

DNS查找过程

客户端向本地域名服务器发出请求，请求www.baidu.com的IP地址
本地DNS服务器向DNS根服务器发出请求，根DNS服务器会告诉本地服务器(.com)的服务器地址
本地DNS服务器会向(.com域)发请求，会得到(baidu.com)的服务器地址
本地DNS服务器会向(baidu.com)发请求,会得到(www.baidu.com)的IP地址61.135.169.125
本地DNS服务器向客户端回复域名(www.baidu.com)对应的IP地址是61.135.169.125

SQL 注入、XSS 攻击、CRFS攻击

XSS攻击

XSS：即 Cross Site Script，跨站脚本，顾名思义，就是恶意攻击者利用网站漏洞往Web页面里插入恶意代码。

借助js实现的攻击，在服务端没有对<>进行转译显示的时候发生。导致用户在浏览页面时会运行xss攻击插入的js代码。可以获取cookie信息等敏感信息。

从本质上讲，XSS漏洞终究原因是由于网站的Web应用对用户提交请求参数未做充分的检查过滤。

解决方案：

HttpOnly 防止劫取 Cookie

用户的输入检查

服务端的输出检查

SQL注入攻击

利用服务器拼接sql字符串，拼接出各种sql，在服务端执行。使服务端数据泄露，甚至被任意篡改。

解决方案：采用sql预编译。 sql预编译就是事先生成模板，然后填入参数，严格按参数类型进行填入。

CRFS攻击

CSRF，即 Cross Site Request Forgery，跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。

通常情况下，CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。

解决方案：

验证码

Referer Check

Token验证

同源策略和跨域

浏览器只对XHR(XMLHttpRequest)请求有同源请求限制，同源就是协议、域名和端口号一致，不同源的客户端脚本在没有明确授权的情况下，不能读写对方XHR资源，反之不同源脚本读取对方XHR资源就是跨域。

下面以www.a.com/test/index.… 的同源检测举例：

www.a.com/dir/page.ht… ----成功
www.child.a.com/test/index.… ----失败，域名不同
www.a.com/test/index.… ----失败，协议不同
www.a.com:8080/test/index.… ----失败，端口号不同

跨域解决方案

通过jsonp跨域
document.domain + iframe跨域
location.hash + iframe
window.name + iframe跨域
postMessage跨域
跨域资源共享（CORS）（较常使用）
nginx代理跨域
nodejs中间件代理跨域（较常使用）
WebSocket协议跨域

参考学习：

前端常见跨域解决方案（全）

CORS原理和设置

CORS是基于http1.1的一种跨域解决方案，它的全称是Cross-Origin Resource Sharing，跨域资源共享。

总体思路：如果浏览器要跨域访问服务器的资源，需要获得服务器的允许。

简单请求

请求头中会自动添加Origin字段。服务器端可以通过请求头中的 Origin 字段，来判断某个请求是否跨域请求。
服务器响应头中应包含Access-Control-Allow-Origin。Access-Control-Allow-Origin 的值为发起跨域请求的那个域名，表示允许这个域名的网页访问当前资源。

需要预检的请求

浏览器发送预检请求，询问服务器是否允许
服务器允许
浏览器发送真实请求
服务器完成真实的响应

在AJAX请求中打开withCredentials属性。xhr.withCredentials = true;
如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。注：对于附带身份凭证的请求，服务器不得设置 Access-Control-Allow-Origin 的值为*。

html 的 crossorigin 属性

添加这个属性，并且服务器允许跨域后，会得到精确的报错信息。

添加这个属性，但服务器不允许跨域，就会被同源策略阻止加载资源。

不添加这个属性，只能知道报错，不知道具体信息。

正向代理和反向代理

正向代理隐藏真实客户端，反向代理隐藏真实服务端。

正向代理：比如访问外网。在国外搭建一台代理服务器，让代理帮我们去请求google.com，代理把请求返回的相应结果返回给我们。

反向代理：比如网站的负载均衡。访问www.baidu.com时，背后可能有成千上万台服务器为我们服务，但不用知道是具体哪一台，只需要知道反向代理服务器是www.baidu.com就好了。

CDN缓存加速

将静态资源文件缓存在距离用户最近位置的服务器上。因此用户在请求访问网站时，可以快速获得自己想要的内容。

工作原理

网站使用了CDN缓存加速后，用户发送请求访问，首先通过DNS重定向技术确认距离用户最近的CDN节点，并且将用户的请求指向此节点。如果该节点没有客户需要的内容结果，缓存服务器就会在源站点服务器中搜寻客户的需要的内容结果，找到后将结果保存到缓存服务器的本地，最后将用户请求所需的内容结果返回至用户端。保存是为了该用户或者不同用户第二次访问请求同样问题的结果，可以再很短的时间返回给客户结果，这样就加快了对用户端的响应速度。

URL和URI

URI：统一资源标识符，用来标识抽象或物理资源的一个紧凑字符串。

URL：统一资源定位符，一种定位资源的主要访问机制的字符串。

URN：统一资源名称，通过特定命名空间中的唯一名称或ID来标识资源。

URI包括URL和URN两个类别，URL是URI的子集。

URI能够唯一标识一个资源，URL在此基础上还提供了资源的位置信息。

带你了解前端需要知道的计网知识