计算机网络

4 minutes read
计算机体系知识
面试 • 计算机网络

计算机网络

OSI模型

  1. 应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
  2. 表示层（数据）：主要解决拥护信息的语法表示问题，如加密解密
  3. 会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，如服务器验证用户登录便是由会话层完成的
  4. 传输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制等
  5. 网络层（包）：提供逻辑地址（IP）、选择最佳路径，数据从源端到目的端的传输
  6. 数据链路层（帧）：将上层数据封装成帧，用 MAC 地址访问媒介，错误检与修正
  7. 物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等

在TCP/IP五层中，123层对应应用层

每层的设备

  • 路由器（网络层）基于数据包的IP地址转发数据包。路由选择、存储转发
  • 交换机（数据链路层、网络层）基于数据帧的MAC地址发送数据帧。识别MAC地址进行转发
  • 网桥（数据链路层）连接两个LAN，根据MAC地址转发帧
  • 集线器（HUB，物理层）连接计算机等网络终端
  • 中继器（物理层）在比特级别对网络信号进行再生和重定时，从而使得它们能够在 网络上传输更长的距离

每层的协议

应用层：http、https、ftp、DNS、SMTP、PoP3、RDP 传输层：TCP、UDP 网络层：IP（RIP、OSPF、BGP 都是选择最短路径的协议） ICMP、IGMP、ARP

数据链路层

三个基本问题

  • 封装成帧：帧开始SOH，帧结束EOT。添加首部和尾部构成帧，进行定界。

  • 透明传输：借助于转义字符ESC，接收之后去掉。ESC EO防止帧中EOT被当作结束。

  • 差错检测：

    • 比特差错：传输过程，1变成0，0变成1

    • 误码率：错误比特数 / 总比特数

    • 借助循环冗余检验（相同得0，不同得1，不进位，也称模二运算）

      1568096942497

  • 算完后，加到000的位置-101001001，收到后，把这个数除除数，余数为0则没差错。

数据链路层的最小MTU 为 64 字节，最大 MTU 为 1500 字节。

点对点协议

PPP：用户到ISP通信所用的数据链路层协议。

以太网通信协议

CSMA/CD（载波监听、多点接入、碰撞检测）

  1. 计算器连接外部局域网是通过适配器adapter进行的，计算机网卡NIC
  2. 半双工情况发生的，早期网络中使用。全双工就不必须要
  3. 检测原理：
    • 检测总线是否空闲，空闲则发送数据，避免碰撞。两个计算机同时发送数据，会发生碰撞
    • 如果不空闲，会监听电缆有流量，等待电缆空闲再发送。发送的同时检测碰撞，没有碰撞代表发送成功
    • 如果发生碰撞，会停止发送数据，并发送干扰信号，其他计算机会感知。这两个发生碰撞的计算机会等待随机时间，再发送数据。每台计算机，等待的时间是随机的，所确保冲突不再发生

MAC地址

  1. 一共48位，前24厂家，后24厂家自定
  2. 单播：帧MAC地址和硬件相同。广播：一对全体，MAC全1。多播。
  3. 帧格式：1565838439228
    • 类型：上层协议。数据字段：64 - 18 = 46（最小）
    • 有效MAC帧长：64~1518

网络层

IP地址和物理地址

  1. IP地址决定数据报最终到达位置，MAC地址决定数据帧的下一跳
  2. IP地址 => ARP解析 => 物理地址，IP地址 <= RARP请求 <= 物理地址

ICMP

为了提高IP数据报交付的成功的机会，用于探测网络故障

类型：差错报文（通或不通）、询问报文

IGMP

IGMP互联网组管理协议是TCP/IP 协议族中负责IP组播成员管理的协议，用来在IP主机和与其直接相邻的组播路由器之间建立、维护组播组成员关系。

ARP

ARP的作用

IP 地址 -> 对应的硬件地址提供动态映射

点对点链路不使用ARP

ARP高速运行的关键

每个主机上有一个ARP高速缓存

ARP运行过程

  1. A查找自己的ARP缓存表，看IP是否有匹配的MAC地址

  2. 如果没有，A会向网络发送广播：这个IP对应的MAC地址是什么

  3. 具有此IP的计算机会向A回应

  4. A收到回应的MAC地址后就可以开始通信了（会写入A的ARP缓存表）

    缓存表内的记录有两种：动态（收到回应后存进去的，长时间不使用会刷新）、静态（用户通过工具或命令添加的arp -s ip mac，减少广播）

ARP报文

1566632524439

记忆：共28字节。以太网先目的后源地址，ARP先发送后目的端。先硬件后协议。

帧类型：ARP： 0x0806

ARP 首部：

  • 硬件类型（1表示以太网地址）、协议类型（0x0800表示IP地址）
  • 硬件地址长度（6）、协议地址长度（4）
  • 操作类型（2）：ARP 请求 1， ARP 回复 2， RARP 请求 3， RARP 应答 4。
  • 发送者硬件地址（6）
  • 发送者IP地址（4）
  • 目的硬件地址（6）
  • 目的IP地址（4）
  • CRC校验（4）

ARP缺点

  1. 缓存：地址刷新有时间限制，可以通过下次更新之前的修改计算机上的地址缓存，造成拒绝服务或ARP欺骗
  2. 广播：攻击者伪装成ARP应答
  3. ARP没有认证，都是合法的。可以在不接受请求的时候就发送应答包

IP

IP不可靠和无连接

  • 不可靠：不保证数据报能成功到达目的地，丢包后发ICMP给信源端。可靠性由上层提供。
  • 无连接：不维护后续数据报的状态信息。A发送的连续数据报，通过的路由选择可能不一样，路线不一样，到达的时间也不一样。

IP报文各字段的含义

1565854542219

  1. 版本 4位：IPV4还是IPV6
  2. 首部长度 4位：首部有多长（因为有可变部分）
  3. 区分服务 8位：标记数据包哪个服务更优先
  4. 总长度 16位：首部+数据部分（数据包有多大）
  5. 标识 16位：计数器，每产生一个数据包就加1
  6. 标志 3位：MF=1，表示后面还有分片。MF=0表示最后一个分片
  7. 片偏移 13位：数据包片第一个在原分组中的相对位置，相对用户数据字段的起点
  8. 生存时间TTL 8位：Windows一般是128，过一个路由器就减一。ping xxx -i 5 代表5个路由器就过期。
  9. 协议 8位：上层协议的类型，6-TCP、17-UDP
  10. 首部校验和 16位：检验首部里面是否有错误
  11. 源IP地址、目的IP地址 32位
  12. 可选字段：排错、测量、安全
  13. 填充

总长度字段

因为一些数据链路（以太网）需要填充一些数据以达到最小长度。因为以太网帧的最小长度是 46 个字节，但是 IP 长度可能更短，所以需要总长度来确定 IP 数据部分的内容。

分组转发

路由表：（目的地址，下一跳地址）

流程：

1. 从数据包首部提取目的IP为D，网络地址N
  1. 若N是直接与本路由器相连的，直接交付（目的主机地址D转换为硬件地址，数据报封装成MAC帧，再发送），否则间接交付，to3
  2. 若路由表中有目的地址为D的特定主机路由，则把数据报传给路由表中指明的下一跳路由。否则 to 4
  3. 若路由表中有到达网络N的路由，则把数据包传送给表中所指的下一跳路由，否则to5
  4. 若路由表内有默认路由，则发送给默认路由，否则to6
  5. 报告转发分组出错

传输层

熟知端口号（系统端口号）：0~1023
```
FTP_传输: 20|FTP_连接: 21｜SSH: 22｜TELNET: 23|SMTP: 25
DNS: 53|TFTP: 69|SNMP: 161|HTTPS: 443
登记端口号：1024~49151
客户端端口号（短暂端口号）：49152~65535
```

TCP

报文段

1565941367722

  1. 源端口、目的端口。两个字节，16位
  2. 序号：2字节。该分段第一个字节是整个文件的第几个字节
  3. 确认号：B发向A，期待收到下个数据包的起始字节号
  4. 数据偏移：第多少个字节后开始是数据部分。四位1111=15x4字节=60个字节，故TCP首部最长60个字节，选项长度最长为40。
  5. 保留：暂时无用
  6. ==URG==：紧急，等于1时，表示紧急数据，优先传送。比如Ctrl+C
  7. ==ACK==：等于1时确认号字段才有效。等于0时无效。
  8. ==PSH==：对比URG，A希望发送后立即接收到B的响应
  9. ==RST==：置1，表示TCP连接出现严重差错，需要释放再重新建立连接
  10. ==SYN==：连接建立时用来同步序号。配合ACK使用
  11. ==终止FIN==：释放连接信号。配合ACK使用
  12. 窗口：[0， 2^16 - 1]，接收方B让发送方A设置其连接发送窗口的依据。
  13. 校验和
  14. 紧急指针：URG=1时，起作用，指明了数据包结束的位置
  15. 选项：可变长度，可以规定最大数据报长度、选择性确认
  16. 填充：给选项凑够四字节

可靠传输的实现-流量控制，滑动窗口

建立连接(){
    B设定接受窗口为20字节；
    A设定发送窗口为20字节；
}

A逐渐发送数据报
do{
    发送窗口;
}while(20个没发完 && 没收到确认);

B接收窗口(){
    收到的为1~6;
    发送确认数据包，ACK=1，确认号为7;
    窗口右移7个，程序可以读取内容；
}

A收到确认(收到确认号为7){
    向前移动七个窗口;
    删除缓存内的字节;
    开始发送移动后进入窗口的21-25;
}

发生丢失(){
    B发送丢失的确认号;
    A从丢失的确认号发送后面的数据;
}

1565943839736

TCP可靠传输的实现-拥塞控制

  1. 出现拥塞：资源需求总和 > 可用资源，是一个全局性的过程。1565944594092

  2. 慢开始和拥塞窗口

    • 发送方维持一个拥塞窗口，发送方让自己的发送窗口等于拥塞窗口

    • 慢开始、拥塞避免。见下面的图：ssthresh是慢开始门限、cwnd是拥塞窗口

      、rwnd是B接收窗口 1565945685819

  3. 快重传和快恢复

  • 快重传
    1. 快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
    2. 由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量。
  • 快恢复
    1. 采用快恢复算法时，慢开始只在TCP连接建立时和网络出现超时时才使用。
    2. 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。但是接下去并不执行慢开始算法。
    3. 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。
  • 所以发送窗口的实际上限为：min{rwnd， cwnd}。拥塞窗口和B接收窗口取最小值
DDOS使用重复发送SYN和随机IP进行攻击

长时间占用未连接队列，使正常的被丢弃。很多连接处于SYN_RECV状态。

三次握手

1566635621655

  1. 握手步骤

    • A向B发送同步数据包：SYN=1，ACK=0，seq=x
    • B发送数据包回应（B开始处于监听状态）：SYN=1，ACK=1，seq=y（B制定），ack=x+1(由A发的seq确定)
    • A向B发送数据包：无需SYN，ACK=1，seq=x+1，ack=y+1
    • TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1。ack表示期待下一次对方发送的序列号。seq和ack的作用是保证传输可靠性，双方用号码验证数据包的顺序。
    • 记忆：
      • SYN是1-1-不用
      • ACK是0-1-1
      • ack由上一层的seq决定
      • seq是自己制定的，最后一次是本方上次发的 seq+1 = x+1

  2. 为什么需要三次

    为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误

四次挥手

  1. 双方都可以发起释放连接。A向B发送释放报文：FIN=1，seq=u
  2. B收到后，发送确认：ACK=1, seq=v, ack=u+1，A就不向B发了
  3. B发完后，再发送数据包：FIN=1, ACK=1, seq=w, ack=u+1
  4. A收到后，A给B确认：ACK=1, seq=u+1, ack=w+1

挥手只能代表发过来的报文接收完了“我OK了”，不能确定对方是否接收完我发的报文。提前关闭会导致另一方永远不能关闭。

记法：
  • FIN 发起方才会有 1- 无-1- 无
  • ACK 应答一次，后面都有
  • ack由上一层seq决定。中间层ack直接继承下来
  • seq前三层各自决定，最后层为本方第一次发送的seq+1 = x+1

1565947913066

其余特性
序列号和确认应答提高可靠性
  • 接收端收到消息会返回一个已收到消息的通知
  • 在一定时间没有确认应答，则发送端重发
  • 为了防止接收端接受重复，有了序列号，确认应答会返回下一个应当接收的序列号
如果建立连接，客户端出故障

  • TCP还设有一个保活计时器，每收到一次请求后都会重新复位这个计时器，时间通常是设置为2小时。

  • 两小时没有任何数据，发送一个探测报文段。75秒发一次，连续发十次没反应，自己关闭连接。

什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

假想网络出问题，最后一个ACK丢失。一个MSL（最大生存时间） 那么B发出FIN后一个MSL内，没有收到回复会再次发送FIN，A在这一个 MSL后才能收到。 所以一共得两个MSL的等待，第二次丢失的话，仍然重复上续步骤。两个等待都没有可以确定关闭。

TCP长连接和短连接
  • 长连接：连接后，发送消息后连接不关闭。保持连接。省去建立和关闭，减少资源浪费。P2P
  • 短连接：一次读写完成后任何一方可以关闭连接。管理简单，存在的连接都是有用的。
    • Web的HTTP服务都用短连接

TCP和UDP

  • TCP：面向连接、可靠交付、字节流、由拥塞控制、首部开销20字节（开销大）、只能一对一、速度慢
  • UDP：非连接、不可靠交付、报 文、无拥塞控制、首部开销8 字节（开销小）、能一/多对多、速度快

网上常规答案。然后又补充说，二者不同的特点对应着不同的适应场景，如视频可以用udp，像QQ打字通信应该tcp。直播中主要用的是基于tcp的RTMP协议，但是udp也有一定的应用，比如YY的直播就是基于udp实现的私有协议。 问: 你怎么知道它们用什么协议的？ 答:YY的协议是在网上了解到的，斗鱼的协议我就比较了解了，因为我在斗鱼有直播间，每次开播的时候需要推流软件填写RTMP服务器URL和推流码。推流码应该是用于身份识别的，避免非斗鱼主播的用户占用推流服务器。 面试官又多问了几句，用斗鱼播什么（游戏，有时候敲代码），有人看嘛有人

TCP保证可靠性的方法

  1. 应用数据被分割成 TCP 认为最适合发送的数据块。
  2. 确认机制，发送报文后，等待确认。
  3. 重发机制，没有收到确认，将重发数据段。
  4. 保持它首部和数据的校验和。 确认数据的准确性。
  5. 排序，丢弃重复的，流量控制。
TCP粘包

TCP粘包，拆包及解决方法

  1. 概述：UDP是不会发生粘包的，因为是基于报文发送的，在UDP首部采用了16bit来指示UDP数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。

    而TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；在TCP的首部也没有表示数据长度的字段，基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

  2. 产生原因：

    发送方发送的多个数据包，到接收方缓冲区首尾相连，粘成一包，被接收。

    接收方不知道该接收多大的数据才算接收完毕，造成粘包。

    • 要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。
    • 待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。
    • 要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。
    • 接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

  3. 解决思路：

    • 发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。
    • 发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。
    • 可以在数据包之间设置边界，开始和结束符，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

应用层

DNS

  • 概念：域名解析，将域名解析为IP，不用去记住IP地址（IP地址可由机器直接读取）
  • 基于UDP，53端口
  • 解析DNS的步骤：
    • 浏览器缓存
    • 本机hosts文件
    • 路由器缓存
    • 查询DNS服务器（本机域名服务器、ISP顶级域名服务器、根域名服务器）
      • 迭代查询（纵向）：没查出来，不是返回0，而是告诉下一个(顶级)域名服务器。本地域名服务器向根服务器（DNS 服务器会向客户机提供其他能够解析查询请求的DNS 服务器地址，当客户机发送查询请求时，DNS 服务器并不直接回复查询结果，而是告诉客户机另一台DNS 服务器地址，客户机再向这台DNS 服务器提交请求，依次循环直到返回查询的结果 为止。）
    • 递归查询（横向）：本机相当于主机，没查出来，返回0，自己找另外的主机。本机向本地域名服务器。本机只发一个DNS报文。
    • https://www.cnblogs.com/qingdaofu/p/7399670.html

HTTP

HTTP报文

1568185424690

HTTP请求报文：请求行、请求头、空行、请求数组

  • 请求行：请求方法字段、URL 字段和 HTTP 协议版本字段 3 个字段组成，它们用空格分隔。
    • GET：车后面拖着。一个数据包
    • POST：车里面。两次包，先头部，收到100 continue。后面再发data
    • HEAD：相当于GET，服务端只返回响应头
  • 请求头：关键字键值对，每行一对
    • User­Agent：产生请求的浏览器类型。
    • Accept：客户端可识别的内容类型列表。
    • Host：请求的主机名，允许多个域名同处一个 IP 地址，即虚拟主机。
  • 空行：表示请求头发完了
  • 请求数据：POST中使用
常见的header头

  • header('HTTP/1.1 100 OK'); // 一切正常

  • header('Location: http://xxxx.xxx/'); // 跳转新地址

  • header('Refresh:10; url=http://xxx.xxx/'); // 延迟几秒跳转

  • header('Content-Type: text/html;charset=utf-8'); 网页编码

  • header('Content-Type:image/jpeg'); 图片文件

  • header('Content-Type:application/octet-stream');header('Content-Disposition:attachment;filename="ITblog.zip"');

    声明一个下载

    1568185497462

HTTP响应报文：状态行、消息响应头、空行、响应正文

  • 状态码：
    • 1xx：指示信息表示请求已接收，继续处理。
    • 2xx：成功表示请求已被成功接收、理解、接受。
    • 3xx：重定向要完成请求必须进行更进一步的操作。
    • 4xx：客户端错误请求有语法错误或请求无法实现。
    • 5xx：服务器端错误服务器未能实现合法的请求。
  • 常见的状态码：
    • 200 OK：客户端请求成功
    • 304 服务端资源无变化，可使用缓存资源
    • 400 Bad Request：客户端请求有语法错误
    • 401 Unauthorized：未经授权
    • 404 Not Found：资源不存在
    • 403 Forbidden：服务器拒绝提供服务
    • 500 Internal Server Error：服务器错误
    • 503 Server Unavailable：服务器当前不能提供服务，一段时间后恢复正常
HTTP的七个步骤

建立TCP连接->发送请求行->发送请求头->（到达服务器）发送状态行->发送响应头->发送响应数据->断TCP连接

  1. 建立TCP连接，80端口
  2. Web浏览器向Web服务器发送请求行。例如：GET /sample/hello.jsp HTTP/1.1
  3. Web浏览器发送请求头。（同header发送信息，之后发送一个空白行表示已经结束发送）
  4. Web服务器接管：服务器应答，第一部分就是协议版本号和状态码
  5. Web服务器发送应答头。发完后发空白行表示结束
  6. 服务器向浏览器发数据。以Content-Type应答头信息所描述的格式发送用户所请求的实际数据
  7. Web服务器关闭TCP连接 。如果浏览器或服务器在请求头加了Connection:keep-alive ，则会保持打开状态。

请求报文包含三部分：

1566645826821

1566552536800

a、请求行：包含请求方法、URI、HTTP版本信息 b、请求首部字段 c、请求内容实体 响应报文包含三部分：

1566646571810

1566552548535

a、状态行：包含HTTP版本、状态码、状态码的原因短语 b、响应首部字段 c、响应内容实体

HTTP1.1新特性 - 1999
  • 多了一些方法：GET , HEAD , POST , PUT , DELETE , TRACE , OPTIONS
  • 缓存处理：加入了更多的缓存控制策略等更多缓存头
  • 新增Host头：一台物理机可以存在多个虚拟主机，共享一个IP。HTTP1并没有投递主机名。HTTP1.1请求消息不带Host头会报错。
  • 新增了24个错误状态响应码
  • 断点续传：从文件已经下载的地方开始继续下载。客户端的Range 和服务器的Content-Range，返回码为206
  • 请求管道化：使得请求可以并行传输，可以发出多个HTTP请求，不用一个个等待。
  • 长连接：支持长连接和请求流水线。一个TCP上可以传送多个HTTP请求响应，减少了建立和关闭连接的消耗时延。默认开启 Connection：keep-alive
SPDY - 2012Google

优化延迟，解决安全性

  • 降低延迟：多路复用，复用多个请求共享一个TCP连接的方式
  • 请求优先级：重要的请求优先响应，首页的html内容优先相应，之后才是资源文件
  • header压缩
  • 基于HTTPS
  • 服务端推送：发送style.css请求时，服务端将style.js一并推送过来，直接从缓存拿。
HTTP2.0 - 2015

HTTP2.0可以说是SPDY的升级版（其实原本也是基于SPDY设计的），但是，HTTP2.0 跟 SPDY 仍有不同的地方

  • 支持明文HTTP传输，SPDY强制HTTPS
  • 消息头压缩算法和SPDY不同
HTTP2.0相对HTTP1.X的新特性

  • 并没有改变语义，只是header和body部分用frame重新封装了一层
  • 新的二进制：HTTP1.X的解析是基于文本的，健壮性缺失
    • 相比文本协议，二进制解析起来更高效，线上更紧凑，错误更少
    • 应用层和传输层之间增加了 二进制分帧层
  • 多路复用：完全的多路复用，并 有序阻塞，只需要一个连接即可实现并行（连接共享）
    • HTTP1.1已经默认采用长连接。但是长连接只减少了建立连接的时间，HTTP 1.1是基于串行文件传输数据，因此这些请求必须是有序的，所以没有办法并行传输。
    • HTTP1.1是基于文本的，只能串行顺序传输，HTTP2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识。这样接收端就可以按照顺序对数据进行合并，从而可以并行的传输数据。
    • HTTP1.X有线端阻塞（head-of-line blocking），一个链接只能提交一个请求的效率比较高，多了会变慢。有流水线方案，但是不理想，（前面的大数据量阻塞后面的请求）且部署较难
    • 很好解决上面的问题，同时处理多个请求和响应。通过request的ID实现
  • Header压缩：降低了开销
    • HTTP1.x的header带有大量信息，而且每次都要重复发送。HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
  • 服务端推送：服务器主动推送到客户端缓存，无需客户端明确请求
HTTP3

上文提到 HTTP/2 使用了多路复用，一般来说同一域名下只需要使用一个 TCP 连接。但当这个连接中出现了丢包的情况，那就会导致 HTTP/2 的表现情况反倒不如 HTTP/1 了。

因为在出现丢包的情况下，整个 TCP 都要开始等待重传，也就导致了后面的所有数据都被阻塞了。但是对于 HTTP/1.1 来说，可以开启多个 TCP 连接，出现这种情况反到只会影响其中一个连接，剩余的 TCP 连接还可以正常传输数据。

基于这个原因，Google 就更起炉灶搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，HTTP/3 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。

QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议。

HTTPS - 443

  • http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，通信过程非常容易遭遇劫持、监听、篡改

  • 以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。加密、签名、证书

  • 加密：

    • 混合加密
      • 公钥交换阶段非对称，更加安全
      • 传输报文时私钥加密，更加高效

  • 数字签名：

    • 对发送报文的摘要用私钥加密，作为签名附在报文
    • 接收后用同样用摘要和私钥加密，和发过来的签名进行对比

  • 数字证书：

    • 浏览器向服务器请求证书
    • 浏览器向可信机构查询该证书
    • 通过，获取公钥。否则发起警告

  • 流程：

    • 客户端发送Client Hello报文发起SSL通信，报文还包括协议版本号、加密算法
    • 服务器发送Server Hello作为应答，报文也包括协议版本号、加密算法
    • 服务器发送数字证书，包含一段公钥
    • 客户端解开并验证证书，通过后生产随机密码，用收到的公钥解密，发送给服务器
    • 客户端发送Change Cipher，用生产的随机密码加密
    • 服务器也发送Change Cipher
    • 连接建立完成，开始传输数据

  • SSL/TLS协议、443端口、对称密钥

  • HTTP无状态、HTTPS有身份认证机制

  • 缺点：

    • 握手费时
    • 连接缓存不高效，会增加数据开销
    • SSL需要绑定IP，不能在一个IP绑定多个域名，IPV4资源有限
    • 不是绝对安全，某些国家掌握CA证书的情况下，会发起中间人攻击
常见的HTTP方法
  • GET、POST、PUT、HEAD、DELETE、OPTIONS
    • GET： 访问被URI（统一资源标识符）识别的资源，通过URL传参给服务器。
    • POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
    • PUT： 传文件，报文主体中包含文件内容，保存到对应URI位置。
    • HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
    • DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
    • OPTIONS：查询相应URI支持的HTTP方法。
HTTP状态码
1XX：消息 2XX：成功 3XX：重定向 4XX：请求错误 5XX、6XX：服务器错误

常见：

  • 200 OK 返回正常
  • 304 服务端资源无变化，可使用缓存资源
  • 400 Bad Request 请求参数不合法，有语法错误
  • 401 Unauthorized 未认证，未授权
  • 403 Forbidden 服务端禁止访问该资源
  • 404 Not Found 服务端未找到该资源
  • 500 Internal Server Error 服务端异常
  • 503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

URI和URL

  • URL：(Uniform/Universal Resource Locator 的缩写，统一资源定位符)。

    URI：(Uniform Resource Identifier 的缩写，统一资源标识符)（代表一种标准）。

  • URI 属于 URL 更高层次的抽象，一种字符串文本标准。URI 属于父类，而 URL 属于 URI 的子类。URL 是 URI 的一个子集（http和https开头的）。

  • URI 表示请求服务器的路径，定义这么一个资源。而 URL 同时说明要如何访问这个资源（http://）。

GET和POST区别

  • 常见回答：

    • GET的请求参数是放在URL里（车后面拖着），POST的请求参数是放在请求body里（车厢里面）
    • GET请求的URL传参有长度限制，而POST请求没有长度限制。大多数浏览器对URL限制2k长度，服务器滴哦URL限制64k长度。
    • GET请求的参数只能是ASCII码，所以中文需要URL编码，而POST请求传参没有这个限制
    • GET请求会被浏览器主动cache，而POST不会，除非手动设置。
    • GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。（实际POST被抓包也能看到）

  • 都是基于TCP/IP

  • GET也可以带request body，但是有的浏览器不一定可以接收到。

  • GET产生一个TCP数据包

    • 浏览器会把http header和data一并发送出去，服务器响应200（返回数据）

  • POST产生两个TCP数据包

    • 浏览器先发送header，服务器响应100 continue

    • 浏览器再发送data，服务器响应200 ok（返回数据）

    • 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

Others

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

1567670772170

  • DNS 解析:将域名解析成 IP 地址
  • 浏览器向IP发起HTTP会话。TCP 连接：TCP 三次握手
  • 发送 HTTP 请求 （见“HTTP的七个步骤”）
  • 服务器处理请求并返回 HTTP 报文
    • 由WebServer或web服务（Apache、nginx、IIS、Tomcat）处理请求。
    • 对结合配置文件运行脚本，返回html相应。或者提取相应字段，进入控制层，调用模型层的方法访问数据库，
    • 返回相应报文。json键值对。
  • 浏览器解析渲染页面（不同的内核Trident（IE）、Gecko（火狐）、Webkit（Safari、Chrome内核原型）、Blink（Chrome））
  • 断开连接：TCP 四次挥手

unix网络模型

  1. 同步、异步、阻塞、非阻塞

    • 同步：需要不断打电话给渔夫
    • 异步：鱼好了通知你，不需要询问
    • 阻塞：买鱼在码头等着
    • 非阻塞：买鱼不用在码头等着

  2. ５种不同的io模型

    • 同步阻塞I/O：当我们去买码头买鱼，鱼还没上来，我们一直在码头等着鱼钓上来，这就是同步阻塞I/O

    1567329316996

    • 同步非阻塞

      我们不断的问码头的鱼上来没有，上来我们就去拿，这就是同步非阻塞I/O

      1567329365362

    • I/O复用模型

      IO复用的实现方式目前主要有select、poll和epoll select和poll就是当你每次都去询问时，渔民会把所有你点的鱼都轮询一遍再告诉你情况，当大量鱼很长时间都不能准备好的情况下是很低效的。于是，渔民有些不耐烦了，然后就每准备好一种鱼就记下来他。这样每次你再去问的时候，他会直接把已经准备好的鱼告诉你，你再去拿。这就是事件驱动IO就绪通知的方式epoll。

    • 信号驱动式I/O模型

      我们打个电话给渔夫，鱼准备好了通知我们去拿，这就是信号驱动式I/O模型

      1567329467400

    • 异步非阻塞 I/O

      我们打个电话给渔夫，鱼准备好了渔夫给你送过来，这就是异步非阻塞I/O

      1567329545335

    五种IO模型比较：

    1567329571982

加密算法

  • **不可逆：**MD5、SHA、HMAC

  • 可逆：

    • 对称：AES、DES、3DES、Blowfish、IDEA、RC4、RC5、RC6
    • 非对称：RSA、DSA（数字签名）、ECC（移动设备）

  • 记少不记多


分享：