iOS面试题收纳-网络

unravel2025
472 阅读42分钟

OSI网络七层是什么

  1. OSI模型有7层结构，每层都可以有几个子层
  2. OSI的7层从上到下分别是 应用层、表示层、会话层、传输层、网络层、数据链路层、物理层
  3. 其中高层（即7、6、5、4层）定义了应用程序的功能，下面3层（即3、2、1层）主要面向通过网络的端到端的数据流

应用层

  • 面向最终用户的一个接口，如网络服务、软件
    • 典型设备：网关
    • 典型协议、标准和应用：HTTP、FTP、TFTP、SMTP、SNMP、DNS、TELNET、HTTPS、POP3、DHCP 等

表示层

  • 用于数据的展示，其中又包括如何表示、安全、压缩等
    • 典型设备：网关
    • 典型协议、标准和应用：ASCLL、PICT、TIFF、JPEG|MPEG等

会话层

  • 建立、管理、终止会话
  • 对应主机进程，指 本地主机与远程主机正在进行的会话
    • 典型设备：网关
    • 典型协议、标准和应用：RPC、SQL、NFS、X WINDOWS、ASP

传输层

  • 定义传输数据的协议端口号以及流控和差错校验。用于端到端的传输控制
    • 典型设备：网关
    • 典型协议、标准和应用：TCP、UDP、SPX

网络层

  • 进行逻辑地址寻址，实现不同网络之间的路径选择
    • 典型设备：路由器
    • 典型协议、标准和应用：ICMP、IGMP、IPV4/V6、ARP、RARP、APPLETALK

数据链路层

  • 将比特组合成字节进而组合成帧，用MAC地址访问介质，错误发现但不能纠正
  • 为网络层提供数据传送服务，包括链路连接的建立、拆除和分离；对帧的收发和顺序控制
  • 建立逻辑连接、进行硬件地址寻址、差错校验等功能。
  • 主要功能：保证无差错的疏忽链路的数据链接
    • 典型设备：交换机、网桥、网卡
    • 典型协议、标准和应用：802.2、802.3ATM、HDLC、FRAME RELAY

物理层

  • 为设备间的数据通信提供传输媒体和互连设备。建立、维护、断开物理连接（由底层网络定义协议）
  • 主要功能：传输比特流
    • 典型设备：集线器、中继器
    • 典型协议、标准和应用：V.35、EIA/TIA-232

因特网五层模型

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

MAC地址和IP地址的区别

  1. MAC地址就是在媒体接入层上使用的地址，也叫物理地址、硬件地址或链路地址，由网络设备制造商生产时写在硬件内部

  2. IP指使用TCP/IP协议指定给主机的32位地址。

    • IPV4地址由用点分隔开的4个八位组构成，这种写法叫点分十进制格式

  3. IP地址相当于你现在所处的地址，会随着你的移动发生改变，而mac地址相当于你的身份证号这些个人信息，是独一无二的，不会改变的

TCP和UDP区别

TCP是什么

  • TCP(传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议。是专门为了在不可靠的互联网络上提供一个可靠的端到端字节流而设计的，面向字节流。
  • 会有三次握手来建立连接，而且在数据传递时，通过校验和、重传控制、序号标识、滑动窗口、确认应答实现可靠传输还可以对次序乱掉的分包进行顺序控制。在数据传完之后，还会断开连接来节约系统资源

UDP是什么

  • UDP(用户数据报协议)是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去
  • UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境

区别

  1. TCP面向连接；UDP是无连接的，即发送数据之前不需要建立连接
  2. TCP提供可靠的服务。也就是说：通过TCP连接传送的数据，无差错、不丢失、不重复、且按序到达；UDP尽最大努力交付，即不保证可靠交付
  3. UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信
  4. 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
  5. TCP对系统资源要求较多，UDP对系统资源要求较少。

TCP可靠数据传输

  1. 网络层服务（IP服务）是不可靠的。IP不保证数据报的交付，不保证数据报的按序交付，也不保证数据报中数据的完整性。

  2. TCP则是在IP服务上创建了一种可靠数据传输服务，确保一个进程从其接收缓存中读出的数据流是无损坏、无间隔、无冗余、按序的数据流。即该字节流与连接的另一端发出的字节流是完全相同的。

TCP与发送和重传有关的三个主要事件

从上层应用 接收 数据的处理

  1. 将数据封装到一个报文段中交付给IP
  2. 每个报文段都包含一个序号Seq，即该报文段第一个数据字节的字节流编号
  3. 如果定时器还没有为其他报文段而运行，则启动定时器(即不是每条报文段都会启动一个定时器，而是一共只启动一个定时器)
  4. 定时器的过期间隔是TimeoutInterval：由EstimatedRTT和DevRTT计算得来的:TCP的往返时间的估计与超时

超时重传的处理

  1. 发送端在TimeoutInterval内接收不到ACK确认报文段。

  2. TCP通过 重传引起超时的报文段 来响应超时事件，然后重启定时器

发送端超时有两种情况

发送数据超时

直接重传即可

接收端发送ACK超时

  1. 这种情况接收端实际上已经接收到发送端的数据了。那么当发送端超时重传时，接收端会丢弃重传的数据，同时再次发送ACK。

  2. 而如果在TimeoutInterval后接收到了ACK，会收下ACK，但不做任何处理

TCP不会为没有数据的ACK超时重传
  1. 如果在发送两条或多条数据报文段都超时，那么只会重传序号最小的那个，并重启定时器。只要其余报文段的ACK在新重启的定时器超时前到达，就不会重传。
  2. 如果发送序号为100和120的两条数据报文段，序号100的ACK丢失，但收到了序号120的ACK，由于累积确认机制，可以得出接收方已经接收到了序号100的报文段，这种情况也不会去重传。

接收到ACK时的处理

  1. 用TCP状态变量SendBase指最早未被确认的字节的序号。则SendBase - 1 指接收方已正确按序接收到的数据的最后一个字节的序号。
  2. 当收到ACK确认报文段后，会将ACK的值Y与SendBase比较。TCP采用累计确认的方法，所以Y确认来字节编号在Y之前的所有字节都已经收到。
    1. 如果Y比SendBase小，不用理会；
    2. 而如果Y比SendBase大，则该ACK是在确认一个或多个先前未被确认的报文段，因此要更新SendBase变量，如果当前还有未被确认的报文段，TCP还要重启定时器。

小结

  1. 通过超时重传，能保证接收到的数据是无损坏、无冗余的数据流，但并不能保证按序。
  2. 而通过TCP滑动窗口，能够有效保证接收数据有序

TCP流量控制

TCP的流量控制服务

  1. TCP连接的双方主机都会为该TCP连接分配缓存和变量。
  2. 当该TCP连接收到正确、按序的字节后，就将数据放入接收缓存。
  3. 上层的应用进程会从该缓存中读取数据，但不一定是数据一到达就立即读取，因为此时应用程序可能在做其他事务。而如果应用层读取数据相对缓慢，而发送方发送得太多、太快，发送的数据就会很容易地使该连接的接收缓存溢出。
  4. 为此TCP为应用程序提供了流量控制服务（flow-control service），以消除发送方使接收方缓存溢出的可能性。

发送窗口/接收窗口

  1. 流量控制是一个速度匹配服务，即发送方的发送速率与接收方应用程序的读取速率相匹配。
  2. 作为全双工协议，TCP会话的双方都各自维护一个发送窗口和一个接收窗口（receive window）的变量来提供流量控制。
  3. 而发送窗口的大小是由对方接收窗口来决定的，接收窗口用于给发送方一个指示--该接收方还有多少可用的缓存空间。

tcp_send_window.png

发送窗口

发送方的发送缓存内的数据都可以被分为4类:

  • 已发送，已收到ACK

  • 已发送，未收到ACK

  • 未发送，但允许发送

  • 未发送，但不允许发送

  • 发送窗口只有收到发送窗口内字节的ACK确认，才会移动发送窗口的左边界

接收窗口

接收方的缓存数据分为3类：

  • 已接收

  • 未接收但准备接收

  • 未接收而且不准备接收

  • 接收窗口只有在前面所有的报文段都确认的情况下才会移动左边界。

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

rwnd

我们定义以下变量：

  • LastByteRead：接收方应用程序读取的数据流的最后一个字节编号。可以得知，这是接收缓存的起点
  • LastByteRcvd：从网络中到达的并且已放入接收缓存中的数据流的最后一个自己的的编号。
  1. 可以得知：LastByteRcvd - LastByteRead <= RcvBuffer(接收缓存大小)
  2. 那么接收窗口rwnd =RcvBuffer - （LastByteRcvd - LastByteRead）
  3. rwnd是随时间动态变化的，如果rwnd为0，则意味着接收缓存已经满了。
  4. 接收端在回复给发送端的ACK中会包含该rwnd，发送端则会根据ACK中的接收窗口的值来控制发送窗口。

ack丢失问题

  1. 有一个问题，如果当发送rwnd为0的ACK后，发送端停止发送数据。
  2. 等待一段时间后，接收方应用程序读取了一部分数据，接收端可以继续接收数据，于是给发送端发送报文告诉发送端其接收窗口大小，但这个报文不幸丢失了，
  3. 我们知道，不含数据的ACK是不会超时重传的，于是就出现发送端等待接收端的ACK通知||接收端等待发送端发送数据的死锁状态。

解

  1. 为了处理这种问题，TCP引入了持续计时器（Persistence timer），当发送端收到对方的rwnd=0的ACK通知时，就启用该计时器
  2. 时间到则发送一个1字节的探测报文，对方会在此时回应自身的接收窗口大小，如果结果仍为0，则重设持续计时器，继续等待。

TCP拥塞控制

  1. TCP让每一个发送方根据所感知到的 网络拥塞程度 来限制 其 能向连接发送流量的速率。
  2. TCP连接的每一端都是由一个接收缓存、一个发送缓存和几个变量（LastByteRead、LastByteRcvd、rwnd等）组成。
  3. 运行在发送方的TCP拥塞控制机制会跟踪一个额外的变量，即****拥塞窗口cwnd（congestion window）。它对一个TCP发送方能向网络中发送流量的速率进行了限制。
  4. 发送方中未被确认的数据量不会超过cwnd和rwnd的最小值:min(rwnd,cwnd)

TCP发送方如何感知网络拥塞？

冗余ACK（duplicate ACK）

就是再次确认某个报文段的ACK，而发送方先前已经收到对该报文段的确认。

冗余ACK的产生原因

  1. 当接收端接收到失序报文段（该报文段序号大于下一个期望的、按序的报文段）时，丢弃该报文段，不会对该报文段确认。

    TCP不使用否定确认，所以不能向发送方发送显式的否定确认，为了使接收方得知这一现象，会对上一个按序字节数据进行重复确认，这也就产生了一个冗余ACK。

  2. 因为发送方经常发送大量的报文段，如果其中一个报文段丢失，可能在定时器过期前，就会收到大量的冗余ACK。

    一旦收到3个冗余ACK（3个以下很可能是链路层的乱序引起的，无需处理），说明在这个已被确认3次的报文段之后的报文段已经丢失，TCP就会执行快速重传（在该报文段的定时器过期之前重传丢失的报文段）

定义发送方丢包事件

将TCP发送方的丢包事件定义为：要么出现超时，要么收到来自接收方的3个冗余ACK。

感知判断

  1. 当出现过度的拥塞时，路由器的缓存会溢出，导致一个数据报被丢弃。
  2. 丢弃的数据报接着会引起发送方的丢包事件。
  3. 那么此时，发送方就认为在发送方到接收方的路径上出现了网络拥塞。

TCP发送方如何限制其向连接发送流量的速率？

  • 当出现丢包事件时：应当降低TCP发送方的速率。
  • 当对先前未确认报文段的确认到达时，即接收到非冗余ACK时，应当增加发送方的速率。

发送方感知到网络拥塞时，采用何种算法来改变其发送速率？

TCP拥塞控制算法（TCP congestion control algorithm）

包括三个主要部分：慢启动、拥塞避免、快速恢复，其中快速恢复并非是发送方必须的，慢启动和拥塞避免则是TCP强制要求的

慢启动

  1. 当一条TCP连接开始时，拥塞窗口cwnd的值通常置为一个MSS的较小值，这就使初始发送速率大约为MSS/RTT（RTT：往返时延，报文段从发出到对该报文段的确认被接收之间的时间量）。
  2. 而对TCP发送方来说，可用带宽可能比MSS/RTT大得多，TCP发送方希望迅速找到可用带宽的数量。因此，在慢启动状态，cwnd以一个MSS的值开始并且每当收到一个非冗余ACK就增加一个MSS。

tcp_message_slowstart.png

最初cwnd值为1MSS，发送一个报文段M1。收到M1的确认后，cwnd增加为2MSS，这时可以发送两个报文段M2，M3。收到这两个报文段的确认后，cwnd则增加为4MSS，可以发送四个报文段，以此类推...

TCP虽然发送速率起始慢，但在慢启动阶段以指数增长，何时结束？

如果出现丢包事件，TCP发送方将ssthresh（慢启动阈值）设置为cwnd/2

  • 发生由超时引起的丢包事件，并将cwnd重置为1MSS，重启慢启动
  • 当TCP发送方的cwnd值达到或超过ssthresh，再继续翻倍显然不合适。这时将结束慢启动转移到拥塞避免模式。
  • TCP发送方检测到3个冗余ACK，会结束慢启动，并快速重传，即在该报文段的定时器过期之前重传丢失的报文段。且进入快速恢复状态。

拥塞避免

  1. 一旦进入拥塞避免状态，cwnd的值大约是上次遇到拥塞时的值的一半，即距离拥塞并不遥远。

  2. 因此，TCP无法每过一个RTT就将cwnd翻倍。而是每个RTT只增加1MSS，即每收到一个非冗余ACK，就将cwnd增加1/cwnd。

    即假如此时cwnd为10MSS，则每收到一个非冗余ACK，cwnd就增加1/10MSS，在10个报文段都收到确认后，拥塞窗口的值就增加了1MSS。

tcp_message_crowedavoid.png

何时结束拥塞避免的线性增长（每RTT 1MSS）呢？

和慢启动一样，如果出现丢包事件，TCP发送方将ssthresh（慢启动阈值）设置为cwnd/2（加法增大， 乘法减小）

  • 发生由超时引起的丢包事件，拥塞避免和慢启动处理的方式相同。即TCP发送方将ssthresh（慢启动阈值）设置为cwnd/2，并将cwnd重置为1MSS，重启慢启动
  • TCP发送方检测到3个冗余ACK，cwnd为原来的一半加上3MSS，进入快速恢复状态。

tcp_message_crowedavoid1.png

快速恢复（并非是必须的）

  1. 快速恢复是由3个冗余ACK引起的。
  2. 在快速恢复中，对引起TCP进入快速恢复状态的缺失报文段，对收到的每个冗余ACK，cwnd增加1个MSS。
  3. 最终，当对丢失报文段的一个ACK到达时，TCP在降低cwnd后进入拥塞避免状态。
  4. 如果出现超时，和之前一样，即TCP发送方将ssthresh（慢启动阈值）设置为cwnd/2，并将cwnd重置为1MSS，重启慢启动

TCP的拥塞控制是：每个RTT内cwnd线性（加性增）增加1MSS，然后出现3个冗余ACK事件时cwnd减半（乘性减），因此TCP拥塞控制常被称为加性增，乘性减拥塞控制方式

什么是三次握手

  1. 指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立
  2. 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据

tcp_message_threehand.png

第一步

  1. 客户端向服务端发送一条特殊的TCP报文段

    • 报文段不包含应用层数据
    • 报文段首部中SYN控制位被置为1，seq被置为客户端随机选择的一个初始序号x

  2. 客户端和服务端最开始都处于CLOSED状态，发送过该 SYN报文段后，客户端TCP进入SYN_SENT状态。等待服务端发送确认报文段

第二步

  1. 服务端收到SYN报文段后，会为该TCP连接分配TCP缓存和变量，服务端进入SYN_RCVD状态，等待客户端发送确认报文段

  2. 服务端向客户端发送确认报文段。

    1. 报文段不包含应用层数据
    2. 报文段首部的ACK控制位被置为1，ACKnum字段被置为x+1。用于告诉客户端我已确认收到你的消息
    3. 报文段首部中SYN控制位被置为1，seq被置为服务端随机选择的一个初始序号y

第三步

  1. 客户端收到SYNACK报文段后，也为该TCP连接分配缓存和变量，客户端TCP进入ESTABLISHED状态，在此状态，客户端就能发送和接收包含有效载荷数据的报文段了。

  2. 客户端向服务端发送一个确认报文段：

    • 报文段不包含应用层数据
    • 报文段首部的ACK控制位被置为1，ACKnum字段被置为y+1。用于告诉服务端我已确认收到你的消息
    • 因为连接已经建立了，所以该SYN控制位比特被置为0。这个阶段，可以在报文段负载中携带应用层数据。

  3. 收到客户端该报文段后，服务端TCP也会进入ESTABLISHED状态，可以发送和接收包含有效载荷数据的报文段。

什么是四次挥手

参与TCP连接的两个进程中的任何一个都能终止该连接，当连接结束后，主机中的资源（缓存和变量）会被释放。

tcp_message_fourhand.png

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭

  • 当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。
  • 收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。
  • 首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

第一步

  • 客户端应用进程发出一个关闭连接的指令，用来关闭客户端到服务器的数据传送。
  • 这会引起客户端TCP向服务端发送一个特殊的TCP报文段。
    • 报文段首部的FIN控制位被置为1，seq字段被置为x。用于告诉服务端我不再发送数据
  • 同时，客户端进入FIN_WAIT_1状态，等待服务端的带有确认的TCP报文段。

第二步

  • 服务器收到该报文段后会向客户端发送一个确认报文段。
    • 报文段首部的ACK控制位被置为1，ACKnum字段被置为x+1。用于告诉客户端我已确认收到你的消息
  • 服务端TCP进入CLOSE_WAIT状态，对应客户端的TIME_WAIT，表示被动关闭。
  • 客户端收到该报文段后，进入FIN_WAIT_2状态，等待服务端的FIN比特置为1的报文段。

第三步

  • 服务端向客户端的终止报文段
    • 报文段首部的FIN控制位被置为1，seq字段被置为y。用于告诉客户端我不再发送数据
  • 服务端TCP进入LAST_ACK状态，等待服务端最后的确认报文段。

第四步

  • 客户端收到服务端的终止报文段后，向服务端发送一个确认报文段。
    • 报文段首部的ACK控制位被置为1，ACKnum字段被置为y+1。用于告诉服务端我已确认收到你的消息
  • 同时，客户端进入TIME_WAIT状态。
  • 假如ACK丢失，TIME_WAIT状态使TCP客户端重传最后的确认报文，TIME_WAIT通常会等待2MSL（Maximum Segment Lifetime 最长报文段寿命）。经过等待后，连接就正式关闭，重新进入CLOSED状态，客户端所有资源将被释放。
  • 服务端收到该报文段后，同样也会关闭，重新进入CLOSED状态，释放所有服务端TCP资源。

为什么建立连接只用三次握手，而断开连接却要四次挥手？

  • 当客户端数据已发送完毕且知道服务端也全部接收到了时，就会去断开连接。即向服务端发送FIN
  • 服务端接收到客户端的FIN，为了表示接收到了，就会向客户端发送ACK
  • 但此时，服务端可能还在发送数据，并没有关闭TCP窗口的意思，所以服务端的FIN和ACK并不是同步发的，只有当数据发送完了，才会发送FIN
  • 服务端的FIN和ACK需要分开发，并不是像三次握手中那样SYN可以和ACK同步发，所以就需要四次挥手

在四次挥手中，客户端为什么在TIME_WAIT后必须等待2MSL时间呢？

  • 这个ACK报文段有可能丢失，因而使处在LAST_ACK端的服务端收不到对已发送的FIN报文段相应的ACK报文段，从而服务端会去不断重传FIN报文段。

  • 而客户端就能在2MSL时间内收到重传的FIN报文段。接着客户端重传一次确认，重新启动2MSL计时器。直至服务端收到后，客户端和服务端就都会进入CLOSED状态，关闭TCP连接。

  • 如果客户端不等待2MSL时间，而是在发送完ACK确认后立即释放资源，关闭连接，那么就无法收到服务端重传的FIN报文段，因而也不会再发送一次ACK确认报文段，这样，服务端就无法正常进入CLOSED状态，资源就一直无法释放了。

  • 为了保证客户端发送的最后一个ACK报文段能够到达服务端。

如何理解HTTP

  • 超文本传输协议，是短连接，由客户端主动发送请求，服务器做出响应，之后链接断开

  • 基于TCP/IP通信协议来传递数据，用于规定客户端与服务端之间的传输规则，所传输的内容不局限于文本(其实可以传输任意类型的数据)。

  • 属于应用层面向对象的协议，有两类报文：请求报文和响应报文

    • 请求报文：由请求行、请求头部、空行和请求数据4部分组成

    • 响应报文：由三部分组成：状态行、消息报头、响应正文

工作过程分为4步:

  1. 客户端与服务器建立连接
  2. 建立连接后，客户端给服务端发送请求
  3. 服务器收到消息后，给与响应操作
  4. 客户端收到消息后，处理数据，断开连接

HTTP的特点有什么

HTTP 是一个属于应用层的面向对象的协议，HTTP 协议一共有五大特点

支持客户端/服务器模式(C/S)

简单快速

  • 客户端向服务器请求服务时，只需传送请求方法和路径

灵活

  • HTTP允许 传输任意类型的数据 对象。正在传输的类型由Content-Type加以标记

无连接

  • 每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接

无状态

  • HTTP协议是无状态协议。
  • 无状态是指协议对于事务处理没有记忆能力

常用的HTTP方法有哪些

  1. HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法
  2. HTTP1.1新增了五种请求方法： OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法

GET

请求指定的页面信息，并返回实体主体

HEAD

类似于GET请求，只不过返回的响应中没有具体的内容，用于获取报头

POST

  1. 向指定资源提交数据进行处理请求，数据被包含在请求体中。
  2. POST请求可能会导致新的资源建立或已有资源的修改

PUT

从客户端向服务器传送的数据取代指定的文档内容

DELETE

请求服务器删除指定的页面

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

OPTIONS

允许客户端查看服务器的性能

TRACE

回显服务器收到的请求，主要用于测试或诊断

常见的Http状态码有哪些

  • 302是请求重定向
  • 500及以上是服务器错误，如503表示服务器找不到、3840表示服务器返回无效JSON
  • 400及以上是请求链接错误或者找不到服务器，如常见的404
  • 200及以上是正确，如常见的是200表示请求正常

HTTP常用的头部字段，常见的返回状态码和意义

常见的头部字段：

host

  1. 指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。
  2. HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。

referer

  1. 允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。
  2. 如果请求的uri没有自己的uri地址，referer不能被发送。
  3. 如果指定的是部分uri地址，则此地址应该是一个相对地址。

User-Agent

  1. 包含发出请求的用户信息，User Agent也简称UA

Cache-Control

  1. 指定请求和响应遵循的缓存机制。
  2. 在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。
  3. 请求时的缓存指令包括 no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached
  4. 响应消息中的指令包括 public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

Date

  1. 表示消息发送的时间，时间的描述格式由rfc822定义。
  2. Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。

常见的返回状态码

  1. 200（成功） 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。
  2. 201（已创建） 请求成功且服务器已创建了新的资源。
  3. 202（已接受） 服务器已接受了请求，但尚未对其进行处理。
  4. 203（非授权信息） 服务器已成功处理了请求，但返回了可能来自另一来源的信息。
  5. 204（无内容） 服务器成功处理了请求，但未返回任何内容。
  6. 205（重置内容） 服务器成功处理了请求，但未返回任何内容。与 204 响应不同，此响应要求请求者重置文档视图（例如清除表单内容以输入新内容）。
  7. 206（部分内容） 服务器成功处理了部分 GET 请求。
  8. 300（多种选择） 服务器根据请求可执行多种操作。服务器可根据请求者 来选择一项操作，或提供操作列表供其选择。
  9. 301（永久移动） 请求的网页已被永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置。您应使用此代码通知搜索引擎蜘蛛网页或网站已被永久移动到新位置。
  10. 302（临时移动） 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。会自动将请求者转到不同的位置。但由于搜索引擎会继续抓取原有位置并将其编入索引，因此您不应使用此代码来告诉搜索引擎页面或网站已被移动。
  11. 303（查看其他位置） 当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD
  12. 304（未修改） 自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应。由于服务器可以告诉 搜索引擎自从上次抓取后网页没有更改过，因此可节省带宽和开销。
  13. 305（使用代理） 请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。
  14. 307（临时重定向） 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。会自动将请求者转到不同的位置。但由于搜索引擎会继续抓取原有位置并将其编入索引，因此您不应使用此代码来告诉搜索引擎某个页面或网站已被移动。
  15. 400（错误请求） 服务器不理解请求的语法。
  16. 401（身份验证错误） 此页要求授权。您可能不希望将此网页纳入索引。
  17. 403（禁止） 服务器拒绝请求。
  18. 404（未找到） 服务器找不到请求的网页
  19. 405（方法禁用） 禁用请求中指定的方法。
  20. 406（不接受） 无法使用请求的内容特性响应请求的网页。
  21. 407（需要代理授权） 此状态码与 401 类似，但指定请求者必须授权使用代理。如果服务器返回此响应，还表示请求者应当使用代理。
  22. 408（请求超时） 服务器等候请求时发生超时。
  23. 409（冲突） 服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。服务器在响应与前一个请求相冲突的 PUT 请求时可能会返回此代码，以及两个请求的差异列表。
  24. 410（已删除） 请求的资源永久删除后，服务器返回此响应。该代码与 404（未找到）代码相似，但在资源以前存在而现在不存在的情况下，有时会用来替代 404 代码。如果资源已永久删除，您应当使用 301 指定资源的新位置。
  25. 411（需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
  26. 412（未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
  27. 413（请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
  28. 414（请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
  29. 415（不支持的媒体类型） 请求的格式不受请求页面的支持。
  30. 416（请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态码。
  31. 417（未满足期望值） 服务器未满足"期望"请求标头字段的要求。
  32. 500（服务器内部错误） 服务器遇到错误，无法完成请求。
  33. 501（尚未实施） 服务器不具备完成请求的功能。例如，当服务器无法识别请求方法时，服务器可能会返回此代码。
  34. 502（错误网关） 服务器作为网关或代理，从上游服务器收到了无效的响应。
  35. 503（服务不可用） 目前无法使用服务器（由于超载或进行停机维护）。通常，这只是一种暂时的状态。
  36. 504（网关超时） 服务器作为网关或代理，未及时从上游服务器接收请求。
  37. 505（HTTP 版本不受支持） 服务器不支持请求中所使用的 HTTP 协议版本

为什么要用HTTP而不直接用TCP

  1. HTTP连接 = 以HTTP协议为通信协议的TCP连接
  2. TCP/IP协议可以让两个进程通过三次握手建立稳定的通信信道，发送字节流，但两个进程无法理解对方的内容
  3. HTTP协议建立在TCP/IP协议之上，TCP/IP协议可以让两个程序说话，而HTTP协议定义了说话的规则

我们在浏览器的地址栏输入url，然后回车到看到页面发生了什么？

  1. 输入地址回车
  2. 域名解析，浏览器查找对应域名的 IP 地址
  3. 发起TCP的3次握手，连接成功后，浏览器向对应IP地址的服务器发送一个 HTTP 请求
  4. 服务器响应http请求，浏览器得到html代码
  5. 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）
  6. 浏览器对页面进行渲染呈现给用户

关于HTTP请求GET和POST的区别

使用区别

  • GET请求：参数在地址后拼接，不安全，不适合传输大量数据

  • POST请求：参数在请求数据区放着，相对GET请求更安全，并且数据大小没有限制。把提交的数据放置在HTTP包的包体中

表单使用form-urlencoded和multipart/form-data的区别

application/x-www-form-urlencoded

  1. 窗体数据被编码为key/value键值对
  2. 当action为get时候，客户端把form数据转换成一个字符串追加到url后面，用?分割。
  3. 当action为post时候，浏览器把form数据封装到http body中，然后发送到server

multipart/form-data

  1. multipart表示的意思是单个消息头包含多个消息体的解决方案。
  2. multipart媒体类型对发送非文本的各媒体类型是有用的。一般多用于文件上传。

传输数据的大小

  • GET提交时，传输数据就会受到URL长度限制（长度有限制，为2048个字节），
  • POST由于不是通过URL传值，理论上不受限

安全性

  • 通过GET提交数据，用户名和密码将明文出现在URL上，不安全
  • POST的安全性要比GET的安全性高

HTTP请求报文简要说明

  • 请求行：包含请求方法(Method)、请求统一资源标识符(URI)、HTTP版本号

  • 请求头：主要存放客户端想给服务端的附加信息

  • 请求体：真正需要发给服务端的数据

http_request_message_detail.png

响应报文简要说明

  • 响应行：也叫状态行，是服务端返回给客户端的状态信息。包含HTTP版本号、状态码、状态码对应的英文名称

  • 响应头：附加信息，和请求头类似

  • 响应体：服务器返回的真正数据

http_response_message_detail.png

什么是HTTTS

  1. 超文本传输安全协议，是以安全为目标的HTTP通道，简单讲是HTTP的安全版。

  2. 即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL

连接过程简述

HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。在传输的过程中会涉及到三个密钥：

  • 服务器端的公钥和私钥，用来进行非对称加密
  • 客户端生成的随机密钥，用来进行对称加密

https_message_detail.png

  1. 客户端访问HTTPS连接

    客户端会把支持的协议版本列表、加密算法列表、压缩算法列表、随机数C 发给服务端

  2. 服务端发送证书给客户端

    • 服务端接收到加密算法列表后会和自己支持的加密算法列表进行比对，如果不符合，则断开连接。
    • 否则，服务端会在该算法列表中，选择一种对称算法（如AES）、一种公钥算法（如具有特定秘钥长度的RSA）和一种MAC算法发给客户端
    • 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人
    • 在发送加密算法的同时还会把数字证书和随机数S发送给客户端

  3. 客户端验证server证书

    对server公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续

  4. 客户端组装会话秘钥

    如果公钥合格，那么客户端会用服务器公钥来生成一个前主秘钥(Pre-Master Secret，PMS)，并通过该前主秘钥和随机数C、S来组装成会话秘钥

  5. 客户端将前主秘钥加密发送给服务端

    通过服务端的公钥来对前主秘钥进行非对称加密，发送给服务端

  6. 服务端通过私钥解密得到前主秘钥

    服务端接收到加密信息后，用私钥解密得到前主秘钥

  7. 服务端组装会话秘钥

    服务端通过前主秘钥和随机数C、S来组装会话秘钥。至此，服务端和客户端都已经知道了用于此次会话的主秘钥

  8. 数据传输

    客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据 同理，服务端收到客户端发送来的密文，用服务端密钥对其进行对称解密，得到客户端发送的数据

总结：

会话秘钥 = random S + random C + 前主秘钥
  • HTTPS连接建立过程使用非对称加密，而非对称加密是很耗时的一种加密方式
  • 后续通信过程使用对称加密，减少耗时所带来的性能损耗
  • 其中，对称加密加密的是实际的数据，非对称加密加密的是对称加密所需要的客户端的密钥

为什么握手过程需要三个随机数，而且安全性只取决于第三个随机数？

  1. 前两个随机数是明文传输，存在被拦截的风险，第三个随机数是通过证书公钥加密的，只有它是经过加密的，所以它保证了整个流程的安全性。
  2. 前两个随机数的目的是为了保证最终对话密钥的『更加随机性』

什么是对称加密

  1. 加密（encryption）与解密（decryption）用的是同样的密钥（secret key）。
  2. 常见的有AES，DES，3DES等

非对称加密

  1. 它使用了一对密钥，公钥（public key）和私钥（private key）。私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人。
  2. 非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥
  3. 常见的: RSA、ECC（移动设备用）、Diffie-Hellman、El Gamal、DSA（数字签名用）

为什么密钥的传递需要使用非对称加密？

  1. 使用非对称加密是为了后面客户端生成的Pre-mastersecret密钥的安全
  2. 通过上面的步骤能得知，服务器向客户端发送公钥证书这一步是有可能被别人拦截的，如果使用对称加密的话，在客户端向服务端发送Pre-mastersecret密钥的时候，被黑客拦截的话，就能够使用公钥进行解码，就无法保证Pre-mastersecret密钥的安全了

公钥加密计算量太大，如何减少耗用的时间

  • 每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息
  • 由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥(非对称加密)只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间

HTTPS是如何实现验证身份和验证完整性的？

使用数字证书和CA来验证身份

  1. 首先服务端先向CA机构去申请证书，CA审核之后会给一个数字证书，里面包裹公钥、签名、有效期，用户信息等各种信息
  2. 在客户端发送请求时，服务端会把数字证书发给客户端，然后客户端会通过信任链来验证数字证书是否是有效的，来验证服务端的身份。

如何保证公钥不被篡改

  • 将公钥放在数字证书中。只要证书是可信的，公钥就是可信的

使用摘要算法来验证完整性

  1. 在发送消息时，会对消息的内容通过摘要算法生成一段摘要，
  2. 在收到收到消息时也使用同样的算法生成摘要，来判断摘要是否一致

HTTP 与HTTPS区别

  • HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费
  • HTTTP是超文本传输协议，信息是明文传输，HTTPs 则是具有安全性的SLL加密传输协议
  • HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
  • HTTP的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

Scoket连接和HTTP连接的区别：

  • HTTP协议是基于TCP连接的，是应用层协议，主要解决如何包装数据。Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。
  • HTTP连接：短连接，客户端向服务器发送一次请求，服务器响应后连接断开，节省资源。服务器不能主动给客户端响应（除非采用HTTP长连接技术）
  • Socket连接：长连接，客户端跟服务器端直接使用Socket进行连接，没有规定连接后断开，因此客户端和服务器保持连接通道，双方可以主动发送数据，一般多用于游戏。Socket默认连接超时时间是30秒，默认大小是8K（理解为一个数据包大小）

什么是WebSocket，解决了什么问题

  • WebSocket是一个应用层协议，它必须依赖HTTP协议进行一次握手，握手成功后数据就直接从 TCP 通道传输，与HTTP 无关了

  • Websocket的数据传输是以Frame形式传输的，比如会将一条消息分为几个frame，按照先后顺序传输出去。这样做会有几个好处：

    • 大数据的传输可以分片传输，不用考虑数据大小导致的长度标志位不足够的情况
    • 和HTTP的chunk一样，可以边生成数据边传递消息，提高传输效率

  • 总之：WebSocket 的实现分为握手，数据发送/读取，关闭连接

项目中网络层如何做安全处理

  • 尽量使用HTTPS

  • 不要传输明文密码

  • Post并不比Get安全

  • 不要使用301跳转

  • HTTP请求都带上MAC

  • AES使用CBC模式

断点续传如何实现

通过HTTP可以非常方便的实现断点续传。

  1. 断点续传主要依赖于HTTP头部定义的Range，应用可以通过HTTP请求曾经获取失败的资源的某一部分来恢复下载该资源。Range是以字节计算的

  2. 通过这个关键字可以告诉服务器返回哪些数据给我。比如:

    • bytes=500-999 表示第500-第999字节
    • bytes=500- 表示从第500字节往后的所有字节

  3. 然后我们再根据服务器返回的数据，将得到的data数据拼接到文件后面，就可以实现断点续传了

什么是心跳

  • 心跳就是用来定时检测TCP连接的双方是否可用

如何用Charles抓HTTPS的包？其中原理和流程是什么？

流程

  1. 首先在手机上安装Charles证书
  2. 在代理设置中开启Enable SSL Proxying
  3. 之后添加需要抓取服务端的地址

原理

Charles作为中间人，对客户端伪装成服务端，对服务端伪装成客户端。

  • 截获客户端的HTTPS请求，伪装成中间人客户端去向服务端发送HTTPS请求
  • 接受服务端返回，用自己的证书伪装成中间人服务端向客户端发送数据内容。

扯一扯HTTPS单向认证、双向认证、抓包原理、反抓包策略

charles_process.png

什么是MTU？为什么MTU值普遍都是1500？

developer.aliyun.com/article/222…

  1. 最大传输单元，是数据链路层的概念。
  2. MTU限制的是数据链路层的payload，也就是上层协议的大小，例如IP，ICMP等。
  3. 一个标准的以太网数据帧大小是：1518，头信息有14字节，尾部校验和FCS占了4字节，所以真正留给上层协议传输数据的大小就是：1518 - 14 - 4 = 1500

IP、TCP、UDP头部长度汇总

blog.csdn.net/u012327735/…

IP头部

IP头部范围为20B(不含options)~60B

60B是因为header length为4bit，故0b1111*4B(一行的大小) = 60B

UDP头部

UDP头部长度是固定的，为12B(假头部)+8B(真头部) = 20B

TCP头部

跟IP头长度一样，20B~60B，取决于有没有options.

avatar
文章
阅读
粉丝