网络
OSI 七层模型？追问：Socket 在哪一层？WebSocket 有没有用过？
互联网协议按照功能不同分为osi七层和tcp/ip五层或tcp/ip四层，如下图：
套接字是工作在传输层和应用层之间的一个接口，将复杂的tcp/udp协议隐藏在了socket接口后面
并没有用过，做以下了解：
WebSocket 是 HTML5 一种新的协议。它实现了浏览器与服务器全双工通信，能更好的节省服务器资源和带宽并达到实时通讯，它建立在 TCP 之上，同 HTTP 一样通过 TCP 来传输数据，但是它和 HTTP 最大不同是：WebSocket 是一种双向通信协议.
你怎么理解分层和协议？
A. 如何理解分层
分层的理由:
- 独立性 通过分层，每一层值接受下一层提供的特定服务，并且负责为上一层提供特定服务，上下层之间进行交互所遵循的约定叫“接口”，同一层之间的交互所遵循的约定叫做“协议”。每一层可以独立使用，及时系统中某些层次发生变化，也不会波及系统。
- 灵活性好 对于任何一层的改动，只要上下层接口不变，都不会造成系统的问题，有利于每一层功能的扩展和变动。
- 易于实现和维护 将大问题简化为小问题，大系统简化为小层次。比如将网络的通信过程划分为小一些、简单一些的部件,因此有助于各个部件的开发、设计和故障排除。
- 能促进标准化工作 通过分层，定义在模型的每一层实现什么功能,有利于鼓励产业的标准化，同时允许多个供应商进行开发。
分层的原则：
- 各个层之间有清晰的边界,便于理解;
- 每个层实现特定的功能;
- 层次的划分有利于国际标准协议的制定;
- 层的数目应该足够多，以避免各个层功能重复
B. 如何理解协议
协议实际上是一种通信双方共同遵守的规范。比如我需要把性别和年龄传递给另外一台主机，那么我可以定义一个"A 协议"，协议规定数据的前 4 个字节表示性别，后四个字节表示年龄。这样对方主机接收时就知道前 4 个字节是性别，而不会错把它当成年龄来处理。
协议的规范和共同遵守，有利于各个分层之间的交流和处理，也有利于促进协议的标准化过程。
路由器和交换机的工作原理大概是什么，他们分别用到什么协议，位于哪一层
交换机:
二层交换机:
二层交换机是一种在数据链路层工作的网络设备，一般要求支持802.1q（就是划VLAN）、SNMP、限速、广播风暴控制、ACL、组播这些常见的功能；它有多个端口，可以连接不同的设备。交换机根据每个帧中的目标 MAC 地址决定向哪个端口发送数据，此时它需要参考“转发表”
转发表并非手动设置，而是交换机自动学习得到的。当某个设备向交换机发送帧时，交换机将帧的源 MAC 地址和接口对应起来，作为一条记录添加到转发表中。
下图描述了交换机自学过程的原理：
三层交换机
三层交换机具有路由器功能，工作在网络层，在二层的基础上支持如静态路由、RIP(矢量路由选择协议)、OSPF(链路状态路由选择协议)、BGP(边界网关协议)、ISIS(分级的链接状态路由协议)等路由协议，有时候会要求支持MPLS(多协议标签交换)、GRE(通用路由封装协议)、L2TP(工业标准的Internet隧道协议)、IPSec(Internet 协议安全性)等隧道协议。三层交换机上能够对分组报文根据IP地址进行转发。
四到七层交换机
负责处理OSI模型中从传输层至应用层的数据。如果用TCP/IP分层模型来表述，4-7层交换机就是以传输层及其上面的应用层为基础，进行分析数据，并对其进行特定的处理。
例如：对于并发访问量非常大的一个企业级Web站点，使用一台服务器不足以满足前端的访问需要，这时通常会通过多台服务器来分担，这些服务器前端访问的入口地址通常只有一个（企业为了使用者的方便，只会向最终的用户开放一个统一的访问URL）。为了能通过同一个URL将前端访问分发到后台多个服务器上，可以在这些服务器的前端加一个负载均衡器。这种负载均衡器就是4-7层交换机的一种。
此外，实际通信当中，人们希望在网络比较拥堵的时候，优先处理像语音这类对及时性要求较高的通信请求，放缓处理像邮件或数据转发等稍有延迟也并无大碍的通信请求，这种处理被称为宽带控制，也是4-7层交换机的重要功能，还有其他很多功能，例如广域网加速器，特殊应用访问加速以及防火墙等。
路由器
路由器工作在网络层，完成通过路由控制将分组数据发送到目标地址的功能。支持如静态路由、RIP(矢量路由选择协议)、OSPF(链路状态路由选择协议)、BGP(边界网关协议)、EGP(外部网关协议)、ISIS(分级的链接状态路由协议)等路由协议。
路由器中保存着路由控制表，它在路由控制表中查找目标IP地址对应的下一个路由器地址。下图描述了这一过程：
主机A的地址是10.1.1.30,要把数据发往地址为10.1.2.10的主机。在主机A的路由表中，保存了两个字段，由于目标地址10.1.2.10与10.1.1.0/24段不匹配，所以它被发往默认路由10.1.1.1也就是图中路由器1的左侧网卡的IP地址。
路由器1继续在它自己的路由控制表中查找目标地址10.1.2.10，它发现目标地址属于10.1.2.0/24这一段，因此将数据转发至下一个路由器10.1.0.2，也就是路由器2的左侧网卡的地址。
路由器2在自己的路由控制表中查找目标地址10.1.2.10，根据表中记录将数据发往10.1.2.1接口，也就是自己的右侧网卡的IP地址。主机B检查目标IP地址和自己相同，于是接收数据。
[网络面试问题]](www.jianshu.com/p/5553ada4a…)
简介 TCP 和 UDP 区别，他们位于哪一层？
TCP 和 UDP 位于OSI 七层模型的第四层：传输层，区别如下：
1、连接性:
TCP 面向连接（如打电话要先拨号建立连接）;
UDP 是面向无连接的，即发送数据之前不需要建立连接
2、可靠性：
TCP 提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;
UDP尽最大努力交付，即不保证可靠交付
3、传输内容：
TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;
UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、服务性质：
TCP连接只能是点到点的;
UDP支持一对一，一对多，多对一和多对多的交互通信
5、开销：
TCP首部开销20字节;
UDP的首部开销小，只有8个字节
6、信道
TCP的逻辑通信信道是全双工的可靠信道
UDP则是不可靠信道
描述TCP 协议三次握手，四次释放的过程？
TCP 三次握手
-
第一次握手:
客户端将标志位SYN置为1，随机产生一个序列值seq = x，并将该数据包发送给服务端,客户端进入SYN_SENT状态，等待服务端确认。 -
第二次握手:
服务端·收到数据包后由标志位SYN=1，知道客户端请求建立连接，服务端将标志位SYN和ACK都置为1，ack = x + 1，随机产生一个值seq = y, 并将该数据包发送给客户端以确认连接请求，服务端进入SYN_RCVD状态。 -
第三次握手:
客户端收到确认后，检查ack是否为x+1，ACK是否为1，如果正确将标志位ACK置为1，ack = y + 1, 并将该数据包发送给服务端,服务端检查ack是否为y+1，ACK是否为1，如果都正确则连接建立成功，客户端和服务端进入ESTABLISHED状态，完成三次握手，随后客户端与服务端之间开始进行数据传输。
TCP 四次挥手
- 第一次挥手:
客户端发出连接释放报文，并且停止发送数据。将释放数据报文首部的FIN置为1，序列号seq置为u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。 - 第二次挥手:
服务端收到报文后，检查到首部的FIN为1，知道客户端请求释放连接，服务端发出确认报文，并将报文首部的ACK置为1，ack置为u + 1,并且带上自己的序列号v,此时服务端进入CLOSE-WAIT(关闭等待状态)。客户端收到服务端的确认报文后，检查ACK是否为1，ack是否为u+1,如果都正确，客户端进入FIN-WAIT-2(终止等待2)状态。等待服务端发送连接释放报文。 - 第三次挥手:
服务端将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1,ack = u+1,序列号为seq = w(因为在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w)，此时服务端进入LASK-ACK(最后确认)状态，等待客户端确认。 - 第四次挥手:
客户端接收服务器的报文后，检查FIN为1，知道服务端请求释放连接，发出确认报文，ACK = 1，ack = w + 1,seq = u + 1, 此时客户端进入TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。服务端只要收到客户端发出的确认报文，检查ACK是否为1，ack是否为w + 1, 如果都正确，立即进入CLOSE状态。
TCP 三次握手过程？
结合TCP报文结构来看会比较清晰：
1、TCP服务器进程先创建传输控制块TCB，时刻准备接受客户进程的连接请求，此时服务器就进入了LISTEN（监听）状态；
2、TCP客户进程也是先创建传输控制块TCB，然后向服务器发出连接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
3、TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，但是同样要消耗一个序号。
4、TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。
5、当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。
参考：
[网络相关面试题](www.javazhiyin.com/35813.html)
TCP 四次挥手过程？
1、客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2、服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3、客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4、服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5、客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6、服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
参考：
如何改进TCP
采取一块确认的机制
UDP是全双工吗？
所谓全双工，半双工，单工是指面向连接时才有的说法，如果不是面向连接的，没有一个确定的连接的话，怎么会出现半双工这种只准一个来或者一个去的说法呢？ UDP支持一对一，一对多，多对一和多对多的交互通信。如果一定要涉及到全双工的话，大概理解为不仅提供全双工，甚至提供全多工服务，只是UDP是不可靠的服务而已。
为什么要等待2MSL？
MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
一、保证客户端发送的最后一个ACK报文能够到达服务器
因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
二、防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。
客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
为什么建立连接时是三次握手，两次行不行？如果第三次握手失败了怎么处理
A. 为什么是三次握手:
- 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
- 因为在网络请求中，我们应该时刻记住：“网络是不可靠的，数据包是可能丢失的”。
- 假设没有第三次确认，
客户端向服务端发送了SYN，请求建立连接。由于延迟，服务端没有及时收到这个包。于是客户端重新发送一个SYN包。回忆一下介绍TCP 首部时提到的序列号，这两个包的序列号显然是相同的。 - 假设服务端接收到了
第二个 SYN 包，建立了通信，一段时间后通信结束，连接被关闭。这时候最初被发送的SYN 包刚刚抵达服务端，服务端又会发送一次ACK确认。由于两次握手就建立了连接，此时的服务端就会建立一个新的连接，然而客户端觉得自己并没有请求建立连接，所以就不会向服务端发送数据。从而导致服务端建立了一个空的连接，白白浪费资源。 - 在三次握手的情况下，
服务端直到收到客户端的应答后才会建立连接。因此在上述情况下，客户端会接受到一个相同的ACK 包，这时候它会抛弃这个数据包，不会和服务端进行第三次握手，因此避免了服务端建立空的连接。
B. 第三次握手失败了怎么处理
- 按照
TCP 协议处理丢包的一般方法，服务端会重新向客户端发送数据包，直至收到ACK 确认为止。但实际上这种做法有可能遭到SYN 泛洪攻击。所谓的泛洪攻击，是指发送方伪造多个 IP 地址，模拟三次握手的过程。当服务器返回ACK后，攻击方故意不确认，从而使得服务器不断重发ACK。由于服务器长时间处于半连接状态，最后消耗过多的CPU和内存资源导致死机。 - 正确处理方法是
服务端发送RST 报文，进入CLOSE状态。这个RST数据包的TCP首部中，控制位中的RST 位被设置为1。这表示连接信息全部被初始化，原有的TCP通信不能继续进行。客户端如果还想重新建立TCP连接，就必须重新开始第一次握手。
关闭连接时，第四次握手失败怎么处理？
实际上，在第三步中，客户端收到FIN 包时，它会设置一个计时器，等待相当长的一段时间。如果客户端返回的ACK 丢失，那么服务端还会重发FIN并重置计时器。假设在计时器失效前服务器重发的 FIN 包没有到达客户端，客户端就会进入 CLOSE状态，从而导致服务端永远无法收到 ACK 确认，也就无法关闭连接。
示意图如下：
为什么TCP握手是三次，挥手却是四次？（假设客户端主动，服务器端被动）
在TCP三次握手中，服务器端的SYN和ACK是放在一个TCP报文段中向客户端发送的，而在断开连接的过程中，服务器端向客户端发送的ACK和FIN是是分别在两个不同的TCP报文段中。这是因为在服务器端接收到客户端的FIN后，服务器端可能还有数据要传输，所以先发送ACK，服务器端把数据发完之后就可以发送FIN断开连接了。
为什需要三次握手？
《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”
书中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。
假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。
参考：
TCP如何保证可靠传输
○ 数据包校验
○ 超时重传机制
○ 应答机制
○ 对失序数据包重排序
○ TCP还能提供流量控制
TCP 协议是如何进行流量控制，拥塞控制的？
A. 如何进行流量控制:
流量控制以动态调整发送空间大小(滑动窗口)的形式来反映接收端接收消息的能力，反馈给发送端以调整发送速度，避免发送速度过快导致的丢包或者过慢降低整体性能。- 这里采用
滑动窗口机制，一是不用每次发送完成都需要等待收到确认消息才能继续发送，二是参考接收端的接收能力，限制发送数据段大小，避免丢失现象。
B. 如何进行拥塞控制：
- 连接建立的初期，如果
窗口比较大，发送方可能会突然发送大量数据，导致网络瘫痪。因此，在通信一开始时，TCP会通过慢启动算法得出窗口的大小，对发送数据量进行控制。
流量控制是由发送方和接收方共同控制的。刚刚我们介绍了接收方会把自己能够承受的最大窗口长度写在TCP 首部中，实际上在发送方这里，也存在流量控制，它叫拥塞窗口。TCP 协议中的窗口是指发送方窗口和接收方窗口的较小值。
慢启动过程如下：
- 通信开始时，
发送方的拥塞窗口大小为1。每收到一个ACK确认后，拥塞窗口翻倍。 - 由于
指数级增长非常快，很快地，就会出现确认包超时。(超时是因为数据量大导致网络拥塞) - 此时设置一个
“慢启动阈值”，它的值是当前拥塞窗口大小的一半。 - 同时将
拥塞窗口大小设置为1，重新进入慢启动过程。 - 由于现在
“慢启动阈值”已经存在，当拥塞窗口大小达到阈值时，不再翻倍，而是线性增加。 - 随着
窗口大小不断增加，可能收到三次重复确认应答，进入“快速重发”阶段。 (快速重发: 当发送端连续收到三个重复的ack时，表示该数据段已经丢失，需要重发。当收到三个表示同一个数据段的ack时，不需要等待计时器超时，即重新发送数据段（当时这三个ack要在超时之前到达发送端），因为能够收到接收端的ack确认信息，所以数据段只是单纯的丢失，而不是因为网络拥塞导致，) - 这时候，
TCP将“慢启动阈值”设置为当前拥塞窗口大小的一半，再将拥塞窗口大小设置成阈值大小（也有说加 3）。 拥塞窗口又会线性增加，直至下一次出现三次重复确认应答或超时。
以上过程可以用下图概括：
常见的 HTTP 状态码？
**1xx ：信息性状态码 ** 表示服务器已接收了客户端请求，客户端可以继续发送请求
- 100 Continue 初始的请求已经接受，客户应当继续发送请求的其余部分
- 101 Switching Protocols 服务器将遵从客户的请求转换到另外一种协议
2xx ：成功状态码 表示服务器已成功接收到请求并进行处理
- 200 OK 表示客户端请求成功
- 204 No Content 成功，但不返回任何实体的主体部分
- 206 Partial Content 成功执行了一个范围（Range）请求
3xx ：重定向状态码 表示服务器要求客户端重定向
- 301 Moved Permanently 永久性重定向，响应报文的Location首部应该有该资源的新URL
- 302 Found 临时性重定向，响应报文的Location首部给出的URL用来临时定位资源
- 303 See Other 请求的资源存在着另一个URI，客户端应使用GET方法定向获取请求的资源
- 304 Not Modified 服务器内容没有更新，可以直接读取浏览器缓存
- 307 Temporary Redirect 临时重定向。与302 Found含义一样。302禁止POST变换为GET，但实际使用时并不一定，307则更多浏览器可能会遵循这一标准，但也依赖于浏览器具体实现
4xx ：客户端错误状态码 表示客户端的请求有非法内容
- 400 Bad Request 表示客户端请求有语法错误，不能被服务器所理解
- 401 表示请求未经授权，该状态代码必须与 WWW-Authenticate 报头域一起使用
- 403 表示服务器收到请求，但是拒绝提供服务，通常会在响应正文中给出不提供服务的原因
- 404 Not Found 请求的资源不存在，例如，输入了错误的URL
5xx ：服务器错误状态码 表示服务器未能正常处理客户端的请求而出现意外错误
- 500 Internel Server Error 表示服务器发生不可预期的错误，导致无法完成客户端的请求
- 503 表示服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常
参考：
常见的HTTP状态码（HTTP Status Code）说明
从输入URL到页面展示，到底发生了什么？
过程为：
- URL 输入
- DNS 解析
- TCP 连接
- 发送 HTTP请求
- 服务器处理请求
- 服务器响应请求
- 浏览器解析，渲染页面
- 链接结束
参考
另一个答案：
• 查询DNS，获取域名对应的IP地址
○ 浏览器搜索自身的DNS缓存
○ 搜索操作系统的DNS缓存
○ 读取本地的HOST文件
○ 发起一个DNS的系统调用
• 宽带运营服务器查看本身缓存
• 运营商服务器发起一个迭代DNS解析请求
• 浏览器获得域名对应的IP地址后，发起HTTP三次握手
• TCP/IP连接建立起来后，浏览器就可以向服务器发送HTTP请求了
• 服务器接受到这个请求，根据路径参数，经过后端的一些处理生成HTML页面代码返回给浏览器
• 浏览器拿到完整的HTML页面代码开始解析和渲染，如果遇到引用的外部JS，CSS,图片等静态资源，它们同样也是一个个的HTTP请求，都需要经过上面的步骤
• 浏览器根据拿到的资源对页面进行渲染，最终把一个完整的页面呈现给用户
对 Cookie 的认识 ？
HTTP 协议对于发送的请求和响应不做持久化处理。这时候引入了 Cookie 技术用于状态管理。Cookie 对用与登录的状态管理，没有 Cookie 这个技术的话，因为 HTTP 不保存状态，每次打开新网页都必须再次登录。
Cookie 会根据响应报文中的 Set-Cookie 字段来通知客户端自动保存 Cookie。下次请求时会自动发送 Cookie，服务器会比对数据得到状态结果。
Session 和 Cookie 的作用和工作原理？
Cookie（复数形态：Cookies）：是指某些网站为了辨别用户身份、进行session跟踪而储存在用户本地终端上的数据（通常经过加密）。
作用：因为HTTP协议是无状态的，即服务器不知道用户上一次做了什么，这严重阻碍了交互式Web应用程序的实现。在典型的网上购物场景中，用户浏览了几个页面，买了一盒饼干和两饮料。最后结帐时，由于HTTP的无状态性，不通过额外的手段，服务器并不知道用户到底买了什么。为了做到这点，就需要使用到Cookie了。服务器可以设置或读取Cookies中包含信息，借此维护用户跟服务器会话中的状态。
Cookie的根本作用就是在客户端存储用户访问网站的一些信息。典型的应用有
1、记住密码，下次自动登录
2、购物车功能
3、记录用户浏览数据，进行商品（广告）推荐
工作原理：
1.创建 Cookie
当用户第一次浏览某个使用Cookie的网站时，该网站的服务器就进行如下工作
1.1 该用户生成一个唯一的识别码（Cookie id），创建一个Cookie对象
1.2 默认情况下它是一个会话级别的cookie，存储在浏览器的内存中，用户退出浏览器之后被删除。如果网站希望浏览器将该Cookie存储在磁盘上，则需要设置最大时效（maxAge），并给出一个以秒为单位的时间（将最大时效设为0则是命令浏览器删除该Cookie）
1.3 将Cookie放入到HTTP响应报头，将Cookie插入到一个 Set-Cookie HTTP请求报头中
1.4 发送该HTTP响应报文
2.设置存储 Cookie
浏览器收到该响应报文之后，根据报文头里的Set-Cookied特殊的指示，生成相应的Cookie，保存在客户端。该Cookie里面记录着用户当前的信息。
3.发送Cookie
当用户再次访问该网站时，浏览器首先检查所有存储的Cookies，如果某个存在该网站的Cookie（即该Cookie所声明的作用范围大于等于将要请求的资源），则把该cookie附在请求资源的HTTP请求头上发送给服务器
4.读取Cookie
服务器接收到用户的HTTP请求报文之后，从报文头获取到该用户的Cookie，从里面找到所需要的东西
Session:代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续的。Session是一种服务器端的机制，Session 对象用来存储特定用户会话所需的信息
工作原理：创建session、使用session，具体看参考url
作用：Session的根本作用就是在服务端存储用户和服务器会话的一些信息
1、判断用户是否登录
2、购物车功能
参考：
谈对 5G技术的认识？
简单说，5G就是第五代通信技术，主要特点是波长为毫米级，超宽带，超高速度，超低延时。
5G如果要实现端到端的高速率，重点是突破无线这部分的瓶颈。
光速 = 波长 * 频率
为了实现更高效的传输速率必须使用更短的波，5G采用毫米波（1~10 mm）
电磁波的显著特点：频率越高，波长越短，越趋近于直线传播（绕射和穿墙能力越差）。****频率越高，在传播介质中的衰减也越大。
所以，5G需要非常多的微基站。对人体是有益的，减小了辐射。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
Http 和 Https的区别？
1. 安全性：
http是HTTP协议运行在TCP之上。所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。
https是HTTP运行在SSL/TLS之上，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。此外客户端可以验证服务器端的身份，如果配置了客户 端验证，服务器方也可以验证客户端的身份。
2. 证书
https协议需要到ca申请证书，一般免费证书很少，需要交费。
3. 传输协议
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议
4. 端口
http和https使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。
HTTPS 原理?
HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。
HTTPS 是 HTTP 建立在 SSL/TLS 安全协议上的。
在 iOS 中，客户端本地会存放着 CA 证书，在HTTPS 请求时，会首先像服务器索要公钥，获得公钥后会使用本地 CA 证书验证公钥的正确性，然后通过正确的公钥加密信息发送给服务器，服务器会使用私钥解密信息。
HTTPS 相对于 HTTP 性能上差点，因为多了 SSL/TLS 的几次握手和加密解密的运算处理，但是加密解密的运算处理已经可以通过特有的硬件来加速处理。
1. 客户端发起HTTPS请求
这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。
2. 服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。
区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。
这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3. 传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4. 客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。
如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
5. 传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6. 服务段解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。
所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
7. 传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原
8. 客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
HTTP 请求中的 get 和 post 的区别?
- GET使用URL或Cookie传参，而POST将数据放在BODY中，这个是因为HTTP协议用法的约定。并非它们的本身区别。
- GET方式提交的数据有长度限制，则POST的数据则可以非常大，这个是因为它们使用的操作系统和浏览器设置的不同引起的区别。也不是GET和POST本身的区别。
- POST比GET安全，因为数据在地址栏上不可见，这个说法没毛病，但依然不是GET和POST本身的区别。
- 最大的区别主要是GET请求是幂等性的，POST请求不是
HTTP｜GET 和 POST 区别？网上多数答案都是错的！
另一个答案：
• GET 被强制服务器支持
• 浏览器对URL的长度有限制，所以GET请求不能代替POST请求发送大量数据
• GET请求发送数据更小
• GET请求是不安全的
• GET请求是幂等的
• POST请求不能被缓存
• POST请求相对GET请求是「安全」的
• 在以下情况中，请使用 POST 请求:
1. 无法使用缓存文件(更新服务器上的文件或数据库)
2. 向服务器发送大量数据(POST 没有数据量限制)
3. 发送包含未知字符的用户输入时，POST 比 GET 更稳定也更可靠
4. post比Get安全性更高
Session 和 Cookie 的区别?
HTTP 是一种无状态的连接，客户端每次读取web 页面时，服务器都会认为这是一次新的会话。但有时候我们又需要持久保持某些信息，比如登录时的用户名、密码，用户上一次连接时的信息等。这些信息就由 Cookie 和Session 保存。
这两者的根本性区别在于，cookie保存在客户端上，而 session 则保存在服务器中。由此我们还可以拓展出以下结论：
cookie相对来说不安全，浏览器可以分析本地的cookie进行cookie欺骗。session可以设置超时时间，超过这个时间后就失效，以免长期占用服务端内存。- 单个
cookie的大小有限制（4 Kb），每个站点的cookie数量一般也有限制（20个）。 客户端每次都会把cookie发送到服务端，因此服务端可以知道cookie，但是客户端不知道session。
当服务器接收到cookie 后，会根据cookie 中的 SessionID 来找到这个客户的 session。如果没有，则会生成一个新的 SessionID发送给客户端。
谈谈你对 HTTP 1.1，2.0 和 HTTPS 的理解?
一、HTTP
HTTP（超文本传输协议，HyperText Transfer Protocol)是应用层的协议，目前在互联网中应用广泛。
它被设计用于Web浏览器和Web服务器之间的通信，但它也可以用于其他目的。 HTTP遵循经典的客户端-服务端模型，客户端打开一个连接以发出请求，然后等待它收到服务器端响应。HTTP是
无状态协议，意味着服务器不会在两个请求之间保留任何数据（状态）。
二、HTTP1.0 ——构建可扩展性
HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。
三、HTTP1.1 ——标准化的协议
HTTP/1.0的多种不同的实现运用起来有些混乱，HTTP1.1是第一个标准化版本，重点关注的是校正HTTP1.0设计中的结构性缺陷：
- 连接可以重复使用，节省了多次打开它的时间，以显示嵌入到单个原始文档中的资源。
- 增加流水线操作，允许在第一个应答被完全发送之前发送第二个请求，以降低通信的延迟。
- 支持响应分块。
- 引入额外的缓存控制机制。
- 引入内容协商，包括语言，编码，或类型，并允许客户端和服务器约定以最适当的内容进行交换。
- 添加Host 头，能够使不同的域名配置在同一个IP地址的服务器。
- 安全性得到了提高
在http1.1中，client和server都是默认对方支持长链接的， 如果不希望使用长链接，则需要在header中指明connection:close；
四、HTTP2.0——为了更优异的表现
HTTP/2.0在HTTP/1.1有几处基本的不同:
HTTP2是二进制协议而不是文本协议。不再可读和无障碍的手动创建，改善的优化技术现在可被实施。- 这是一个复用协议。并行的请求能在同一个链接中处理，移除了HTTP/1.x中顺序和阻塞的约束。
- 压缩了headers。因为headers在一系列请求中常常是相似的，其移除了重复和传输重复数据的成本。
- 其允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制来提前请求。
五、HTTPS
我们知道HTTP 协议直接使用了TCP 协议进行数据传输。由于数据没有加密，都是直接明文传输，所以存在以下三个风险：
- 窃听风险：第三方节点可以获知通信内容。
- 篡改风险：第三方节点可以修改通信内容。
- 冒充风险：第三方节点可以冒充他人身份参与通信。
比如你在手机上打开应用内的网页时，有时会看到网页底部弹出了广告，这实际上就说明你的HTTP 内容被窃听、并篡改了。
HTTPS 协议旨在解决以上三个风险，因此它可以：
- 保证所有信息加密传输，无法被第三方窃取。
- 为信息添加校验机制，如果被第三方恶意破坏，可以检测出来。
- 配备身份证书，防止第三方伪装参与通信。
HTTPS 的结构如图所示：
可见它仅仅是在 HTTP 和TCP 之间新增了一个TLS/SSL 加密层，这也印证了一句名言：“一切计算机问题都可以通过添加中间层解决”。
使用HTTPS 时，服务端会将自己的证书发送给客户端，其中包含了服务端的公钥。基于非对称加密的传输过程如下：
- 客户端使用公钥将信息加密，密文发送给服务端
- 服务端用自己的私钥解密，再将返回数据用私钥加密发回客户端
- 客户端用公钥解密
这里的证书是服务器证明自己身份的工具，它由权威的证书颁发机构（CA）发给申请者。如果证书是虚假的，或者是自己给自己颁发的证书，服务器就会不认可这个证书并发出警告：
总结一下 HTTPS 协议是如何避免前文所说的三大风险的：
- 先用
非对称加密传输密码，然后用这个密码对称加密数据，使得第三方无法获得通信内容 发送方将数据的哈希结果写到数据中，接收方解密后对比数据的哈希结果，如果不一致则说明被修改。由于传输数据加密，第三方无法修改哈希结果。- 由
权威机构颁发证书，再加上证书校验机制，避免第三方伪装参与通信.
为什么建立连接是三次握手，而关闭连接却是四次挥手呢？
这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。
参考：
