【iOS】架构师之路~ 网络篇

网络

OSI 七层模型？追问：Socket 在哪一层？WebSocket 有没有用过？

互联网协议按照功能不一样分为osi七层和tcp/ip五层或tcp/ip四层，以下图：

套接字是工做在传输层和应用层之间的一个接口，将复杂的tcp/udp协议隐藏在了socket接口后面

并无用过，作如下了解：

WebSocket 是 HTML5 一种新的协议。它实现了浏览器与服务器全双工通讯，能更好的节省服务器资源和带宽并达到实时通信，它创建在 TCP 之上，同 HTTP 同样经过 TCP 来传输数据，可是它和 HTTP 最大不一样是：WebSocket 是一种双向通讯协议.

iOS 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 七层模型的第四层：传输层，区别以下：

一、链接性:
	 TCP 面向链接（如打电话要先拨号创建链接）;
	 UDP 是面向无链接的，即发送数据以前不须要创建链接
二、可靠性：
   TCP 提供可靠的服务。也就是说，经过TCP链接传送的数据，无差错，不丢失，不重复，且按序到达; 
	 UDP尽最大努力交付，即不保证可靠交付
三、传输内容：
	 TCP面向字节流，其实是TCP把数据当作一连串无结构的字节流;
	 UDP是面向报文的，UDP没有拥塞控制，所以网络出现拥塞不会使源主机的发送速率下降（对实时应用颇有用，如IP电话，实时视频会议等）
四、服务性质：
	 TCP链接只能是点到点的;
	 UDP支持一对一，一对多，多对一和多对多的交互通讯
五、开销：
	 TCP首部开销20字节;
	 UDP的首部开销小，只有8个字节
六、信道
	 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报文结构来看会比较清晰：

一、TCP服务器进程先建立传输控制块TCB，时刻准备接受客户进程的链接请求，此时服务器就进入了LISTEN（监听）状态；

二、TCP客户进程也是先建立传输控制块TCB，而后向服务器发出链接请求报文，这是报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了SYN-SENT（同步已发送状态）状态。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但须要消耗掉一个序号。

三、TCP服务器收到请求报文后，若是赞成链接，则发出确认报文。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为本身初始化一个序列号 seq=y，此时，TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据，可是一样要消耗一个序号。

四、TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1，ack=y+1，本身的序列号seq=x+1，此时，TCP链接创建，客户端进入ESTABLISHED（已创建链接）状态。TCP规定，ACK报文段能够携带数据，可是若是不携带数据则不消耗序号。

五、当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就能够开始通讯了。

参考：

[网络相关面试题](www.javazhiyin.com/35813.html)

TCP 四次挥手过程？

一、客户端进程发出链接释放报文，而且中止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。TCP规定，FIN报文段即便不携带数据，也要消耗一个序号。

二、服务器收到链接释放报文，发出确认报文，ACK=1，ack=u+1，而且带上本身的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，可是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

三、客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送链接释放报文（在这以前还须要接受服务器发送的最后的数据）。

四、服务器将最后的数据发送完毕后，就向客户端发送链接释放报文，FIN=1，ack=u+1，因为在半关闭状态，服务器极可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

五、客户端收到服务器的链接释放报文后，必须发出确认，ACK=1，ack=w+1，而本身的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP链接尚未释放，必须通过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

六、服务器只要收到了客户端发出的确认，当即进入CLOSED状态。一样，撤销TCB后，就结束了此次的TCP链接。能够看到，服务器结束TCP链接的时间要比客户端早一些。

参考：

网络相关面试题

如何改进TCP

采起一块确认的机制

UDP是全双工吗？

所谓全双工，半双工，单工是指面向链接时才有的说法，若是不是面向链接的，没有一个肯定的链接的话，怎么会出现半双工这种只准一个来或者一个去的说法呢？ UDP支持一对一，一对多，多对一和多对多的交互通讯。若是必定要涉及到全双工的话，大概理解为不只提供全双工，甚至提供全多工服务，只是UDP是不可靠的服务而已。

为何要等待2MSL？

MSL（Maximum Segment Lifetime），TCP容许不一样的实现能够设置不一样的MSL值。

1、保证客户端发送的最后一个ACK报文可以到达服务器
		由于这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端尚未给我回应，应该是我发送的请求断开报文它没有收到，因而服务器又会从新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，而且会重启2MSL计时器。
2、防止相似与“三次握手”中提到了的“已经失效的链接请求报文段”出如今本链接中。
  	客户端发送完最后一个确认报文后，在这个2MSL时间中，就能够使本链接持续的时间内所产生的全部报文段都从网络中消失。这样新的链接中不会出现旧链接的请求报文。

复制代码

TCP/IP，你必知必会的十个问题

网络相关面试题

为何创建链接时是三次握手，两次行不行？若是第三次握手失败了怎么处理

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端一直等待，浪费资源。

参考：

从输入URL到页面展现，到底发生了什么

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到页面展现，到底发生了什么？

过程为：

• URL 输入
• DNS 解析
• TCP 链接
• 发送 HTTP请求
• 服务器处理请求
• 服务器响应请求
• 浏览器解析，渲染页面
• 连接结束

参考

从输入URL到页面展现，到底发生了什么

从输入URL到页面展现，你想知道些什么？

另外一个答案：

• 查询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.建立 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的根本做用就是在服务端存储用户和服务器会话的一些信息

一、判断用户是否登陆

二、购物车功能

参考：

Cookie和Session的做用和工做原理

谈对 5G技术的认识？

简单说，5G就是第五代通讯技术，主要特色是波长为毫米级，超宽带，超高速度，超低延时。

5G若是要实现端到端的高速率，重点是突破无线这部分的瓶颈。

光速 = 波长 * 频率

为了实现更高效的传输速率必须使用更短的波，5G采用毫米波（1~10 mm）

电磁波的显著特色：频率越高，波长越短，越趋近于直线传播（绕射和穿墙能力越差）。****频率越高，在传播介质中的衰减也越大。

因此，5G须要很是多的微基站。对人体是有益的，减少了辐射。

第一次有人把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. 客户端解密信息
   客户端用以前生成的私钥解密服务段传过来的信息，因而获取了解密后的内容。整个过程第三方即便监听到了数据，也一筹莫展。
复制代码

https工做原理

简单粗暴系列之HTTPS原理

经典面试题21 - HTTPS 和 SSL证书原理

HTTP 请求中的 get 和 post 的区别?

1. GET使用URL或Cookie传参，而POST将数据放在BODY中，这个是由于HTTP协议用法的约定。并不是它们的自己区别。
2. GET方式提交的数据有长度限制，则POST的数据则能够很是大，这个是由于它们使用的操做系统和浏览器设置的不一样引发的区别。也不是GET和POST自己的区别。
3. POST比GET安全，由于数据在地址栏上不可见，这个说法没毛病，但依然不是GET和POST自己的区别。
4. 最大的区别主要是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 的理解?

1、HTTP

HTTP（超文本传输协议，HyperText Transfer Protocol)是应用层的协议，目前在互联网中应用普遍。

它被设计用于Web浏览器和Web服务器之间的通讯，但它也能够用于其余目的。 HTTP遵循经典的客户端-服务端模型，客户端打开一个链接以发出请求，而后等待它收到服务器端响应。HTTP是 无状态协议，意味着服务器不会在两个请求之间保留任何数据（状态）。

2、HTTP1.0 ——构建可扩展性

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

3、HTTP1.1 ——标准化的协议

HTTP/1.0的多种不一样的实现运用起来有些混乱，HTTP1.1是第一个标准化版本，重点关注的是校订HTTP1.0设计中的结构性缺陷：

• 链接能够重复使用，节省了屡次打开它的时间，以显示嵌入到单个原始文档中的资源。
• 增长流水线操做，容许在第一个应答被彻底发送以前发送第二个请求，以下降通讯的延迟。
• 支持响应分块。
• 引入额外的缓存控制机制。
• 引入内容协商，包括语言，编码，或类型，并容许客户端和服务器约定以最适当的内容进行交换。
• 添加Host 头，可以使不一样的域名配置在同一个IP地址的服务器。
• 安全性获得了提升

在http1.1中，client和server都是默认对方支持长连接的， 若是不但愿使用长连接，则须要在header中指明connection:close；

4、HTTP2.0——为了更优异的表现

HTTP/2.0在HTTP/1.1有几处基本的不一样:

• HTTP2是二进制协议而不是文本协议。再也不可读和无障碍的手动建立，改善的优化技术如今可被实施。
• 这是一个复用协议。并行的请求能在同一个连接中处理，移除了HTTP/1.x中顺序和阻塞的约束。
• 压缩了headers。由于headers在一系列请求中经常是类似的，其移除了重复和传输重复数据的成本。
• 其容许服务器在客户端缓存中填充数据，经过一个叫服务器推送的机制来提早请求。

5、HTTPS

咱们知道HTTP 协议直接使用了TCP 协议进行数据传输。因为数据没有加密，都是直接明文传输，因此存在如下三个风险：

• 窃听风险：第三方节点能够获知通讯内容。
• 篡改风险：第三方节点能够修改通讯内容。
• 冒充风险：第三方节点能够冒充他人身份参与通讯。

好比你在手机上打开应用内的网页时，有时会看到网页底部弹出了广告，这实际上就说明你的HTTP 内容被窃听、并篡改了。 HTTPS 协议旨在解决以上三个风险，所以它能够：

• 保证全部信息加密传输，没法被第三方窃取。
• 为信息添加校验机制，若是被第三方恶意破坏，能够检测出来。
• 配备身份证书，防止第三方假装参与通讯。

HTTPS 的结构如图所示：

可见它仅仅是在 HTTP 和TCP 之间新增了一个TLS/SSL 加密层，这也印证了一句名言：“一切计算机问题均可以经过添加中间层解决”。 使用HTTPS 时，服务端会将本身的证书发送给客户端，其中包含了服务端的公钥。基于非对称加密的传输过程以下：

• 客户端使用公钥将信息加密，密文发送给服务端
• 服务端用本身的私钥解密，再将返回数据用私钥加密发回客户端
• 客户端用公钥解密

这里的证书是服务器证实本身身份的工具，它由权威的证书颁发机构（CA）发给申请者。若是证书是虚假的，或者是本身给本身颁发的证书，服务器就会不承认这个证书并发出警告：

总结一下 HTTPS 协议是如何避免前文所说的三大风险的：

• 先用非对称加密传输密码，而后用这个密码对称加密数据，使得第三方没法得到通讯内容
• 发送方将数据的哈希结果写到数据中，接收方解密后对比数据的哈希结果，若是不一致则说明被修改。因为传输数据加密，第三方没法修改哈希结果。
• 由权威机构颁发证书，再加上证书校验机制，避免第三方假装参与通讯.

网络层面试题

为何创建链接是三次握手，而关闭链接倒是四次挥手呢？

这是由于服务端在LISTEN状态下，收到创建链接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭链接时，当收到对方的FIN报文时，仅仅表示对方再也不发送数据了可是还能接收数据，己方也未必所有数据都发送给对方了，因此己方能够当即close，也能够发送一些数据给对方后，再发送FIN报文给对方来表示赞成如今关闭链接，所以，己方ACK和FIN通常都会分开发送。

参考：

从输入URL到页面展现，到底发生了什么