5214 字
26 分钟
计算机网络

[12] http与https的区别#

  • 相同点:两者都是应用层协议,都基于TCP/IP协议传输数据

  • 不同点:

    • http:超文本传输协议,明文传输,基于请求和响应的无状态的协议,端口号80

    无状态是什么意思:协议对于交互性场景没有记忆能力

    • https:安全版的http,在http下加入了SSL层密文传输;主要作用是①建立一个信息安全通道,保证数据传输的安全,②确认网站的真实性。端口号443

    缺点:多次握手 页面加载慢,连接缓存不如http,开销、功耗大,ssl安全计算消耗服务器cpu资源

  • https的工作原理/https的加密过程

    步骤:目标是为了交换会话密钥,利用数字证书和非对称加密实现

    ​ 假设服务器网站公私钥 A 和 a 会话密钥 B

    1. 客户使用https的URL访问服务器,要求与服务器建立SSL连接。

    2. 服务器收到客户端请求后,会将网站的证书信息(证书中包含服务器网站的公钥A)传送一份给客户端。

    3. 客户端收到证书并验证证书合法性,接着与服务器开始协商SSL连接的安全等级。

    4. 客户端根据双方同意的安全等级,建立会话密钥B,然后利用服务器的公钥A会话密钥B加密,并传送给服务器。

    5. 服务器利用自己的私钥a解密出会话密钥B

    6. 服务器利用会话密钥B加密与客户端之间的通信。

    拓展:彻底搞懂HTTPS的加密原理 - 知乎 (zhihu.com)

    数字签名 数字证书 非对称加密

[11] http响应状态码#

HTTP 状态码 | 菜鸟教程 (runoob.com)

100、101、200、301、302、304、403、404、500

[12] 三次握手#

为什么要三次握手

本质其实是确认客户端和服务端的接收和发送能力都没问题

1、第一次握手:客户端发送请求,服务器收到请求(服务器知道客户端能发)

2、第二次握手:服务端发送确认响应(客户端知道服务器能发也能收)

3、第三次握手:客户端发送确认响应(服务器知道客户端能收)

为了实现可靠数据传输,三次握手的过程即是通信双方相互告知序列号seq=x/seq=y起始值, 并确认对方已经收到了序列号起始值(以确认号 ack=x+1/ack=y+1来告诉对方) 如果只是两次握手, 至多只有连接发起方的起始序列号能被确认, 另一方选择的序列号则得不到确认。

TCP 为什么三次握手而不是两次握手(正解版)_萧萧九宸的博客-CSDN博客_tcp为什么是三次握手不是两次握手

![image-20241217122718019](/Users/guang/Library/Application Support/typora-user-images/image-20241217122718019.png)

​ 图里的过程可能需要自己描述一下

[8] get和post的区别#

getpost
用来获取数据用来提交数据
参数(附加在url上)有长度限制(受限于url)参数无限制(存储于请求体内)
不安全看似安全,其实也不安全,还得靠https
get请求参数会被浏览器主动缓存,保留在历史记录中post中参数不会保留
只产生一个TCP数据包产生两个TCP数据包

扩展:

  • GET产生一个TCP数据包;POST产生两个TCP数据包。
  • 缓存的角度,GET 请求会被浏览器主动缓存下来,留下历史记录,而 POST 默认不会。
  • 编码的角度,GET 只能进行 URL 编码,只能接收 ASCII 字符,而 POST 没有限制。
  • 参数的角度,GET 一般放在 URL 中,因此不安全,POST 放在请求体中,更适合传输敏感信息。
  • 幂等性的角度,GET幂等的,而POST不是。(幂等表示执行相同的操作,结果也是相同的)

为什么GET产生一个TCP数据包;POST产生两个TCP数据包呢

对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);

而对于POST,浏览器先发送请求头header,服务器响应100 continue,浏览器再发送请求体data,服务器响应200 ok(返回数据)。

[8] 从浏览器输入url到页面展示的过程#

简单版

  1. 解析域名,找到主机 IP。

  2. 浏览器利用 IP 直接与网站主机通信,三次握手,建立 TCP 连接。浏览器会以一个随机端口向服务 端的 web 程序 80 端口发起 TCP 的连接。

  3. 建立 TCP 连接后,浏览器向主机发起一个HTTP请求。

  4. 服务器响应请求,返回响应数据。

  5. 浏览器解析响应内容,进行渲染,呈现给用户。

拓展:【干货】浏览器是如何运作的?_哔哩哔哩_bilibili 详细的浏览器解析渲染过程

[8] http的1.0、1.1、2.0的区别和一些特性#

HTTP1.1相比HTTP1.0支持的特性:

​ http1.0是无状态、无连接的应用层协议

  • http1.1基于文本解析,把所有请求和响应作为纯文本
  • http1.1加入了缓存处理(强缓存和协商缓存)
  • http1.1拥有长连接,并支持请求管道化pipelining),
  • http1.1流控制基于tcp连接

HTTP2.0相比HTTP1.1支持的特性:

  • 新的二进制格式:HTTP1.1 基于文本格式传输数据;HTTP2.0采用二进制格式传输数据,解析更高效。
  • 多路复用:在一个连接里,允许同时发送多个请求或响应,并且这些请求或响应能够并行的传输而 不被阻塞,避免 HTTP1.1 出现的”队头堵塞”问题。
  • 头部压缩,HTTP1.1的header带有大量信息,而且每次都要重复发送;HTTP2.0 把header从数据中分离,并封装成头帧和数据帧,使用特定算法压缩头帧,有效减少头信息大小。并且HTTP2.0在客户端和服务器端记录了之前发送的键值对,对于相同的数据,不会重复发送。比如请求a发送了所有的头信息字段,请求b则只需要发送差异数据,这样可以减少冗余数据,降低开销。
  • 服务端主动推送:HTTP2.0允许服务器向客户端推送资源,无需客户端发送请求到服务器获取。
  • 性能提升以及允许实现自己的流控制机制

[8] TCP与UDP的区别#

  1. TCP面向连接;UDP是无连接的,即发送数据之前不需要建立连接。

  2. TCP提供可靠的服务,效率低;UDP不保证可靠交付。

  3. TCP面向字节流,把数据看成一连串无结构的字节流;UDP是面向报文的。

  4. TCP有拥塞控制;UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应 用很有用,如实时视频会议等)。

  5. 每一条TCP连接只能是一对一的;UDP支持一对一、一对多、多对一和多对多的通信方式。

  6. TCP首部开销20字节;UDP的首部开销小,只有8个字节。

    应用场景

    TCP:FTP文件传输,浏览器http/https请求

    UDP: 视频,音频

[7] 四次挥手#

  • 为什么要四次挥手:由于 TCP 的半关闭特性,TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力,也就是说客户端单方面关闭连接还能接收到服务端的数据报文,服务端需要把所有报文都发送完才会关闭自己的连接。通俗的来说,两次握手就可以释放一端到另一端的 TCP 连接,完全释放连接一共需要四次握手。

    ![image-20241217122236709](/Users/guang/Library/Application Support/typora-user-images/image-20241217122236709.png)

    细节描述可能需要自己归纳一下

    1. A的应用进程先向其TCP发出连接释放报文段( FIN=1,seq=u ),并停止再发送数据,主动关闭 TCP连接,进入 FIN-WAIT-1 (终止等待1)状态,等待B的确认。
    2. B收到连接释放报文段后即发出确认报文段( ACK=1,ack=u+1,seq=v ),B进入 CLOSE-WAIT (关闭等待)状态,此时的TCP处于半关闭状态,A到B的连接释放。
    3. A收到B的确认后,进入 FIN-WAIT-2 (终止等待2)状态,等待B发出的连接释放报文段。
    4. B发送完数据,就会发出连接释放报文段( FIN=1,ACK=1,seq=w,ack=u+1 ),B进入 LAST-ACK (最后确认)状态,等待A的确认。
    5. A收到B的连接释放报文段后,对此发出确认报文段( ACK=1,seq=u+1,ack=w+1 ),A进入 TIMEWAIT (时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间 2MSL (最大报 文段生存时间)后,A才进入 CLOSED 状态。B收到A发出的确认报文段后关闭连接,若没收到A发出 的确认报文段,B就会重传连接释放报文段。
  • 为什么要等待2MSL

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

    • 防止已失效的连接请求报文段出现在本连接中

      A在发送完最后一个 ACK 报文段后,再经过2MSL, 就可以使这个连接所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现旧的连接请 求报文段。

[6] http缓存策略#

  • 为什么使用缓存

    缓存说白了就是为了快,缓存主要是针对数据的复用,无论是从磁盘到内存还是从网络到本地,都是为了在下次实用此资源的时候,能够快速响应,避免多次的 I/O 操作

    存的是什么:请求资源的一个副本,下一次请求直接从缓存提取,不需要再向服务端获取

  • 缓存策略

    • 缓存失效:需要有一个条件来判定当前缓存的数据,是否依然有效。
    • 减少读取:让服务端通知客户端,当前缓存依然有效,可以继续使用。
  • http缓存主要通过报文头的Header信息来控制缓存策略

    • Cache-Control:设定缓存策略,是否使用缓存,超时时间是多少。

    • ETag:当前返回数据的验证令牌,相当于数据的指纹,下次请求时携带上

      发送下一次请求将令牌发至服务端,判断令牌指纹和服务端当前数据是否一致,未发生变化,返回304,表示可以直接使用本地缓存的数据,并刷新超时事件

  • 缓存策略树:因场景来设定

    总结:

    http缓存依赖 URL 做唯一标识,不同的 URL 使用不同的缓存。

    Cache-Control 可以控制缓存策略,共有或者私有、缓存超时时长等。

    通过 ETag 来标记数据指纹令牌,以此来确定响应数据是否更新。

    应该为每个响应资源提供对应的缓存策略。

    如果需要废弃之前的缓存,可以利用修改请求 URL 的方式,将数据指纹令牌追加在 URL 之后,以此来更新数据。 链接:https://juejin.cn/post/6844903624988966926

[5] http的请求方法#

HTTP 请求方法 | 菜鸟教程 (runoob.com)

[4] Dns工作原理、优化#

DNS域名解析系统

  1. 浏览器搜索自己的DNS缓存

  2. 若没有,则搜索操作系统中的DNS缓存和hosts文件

  3. 若没有,则操作系统将域名发送至本地域名服务器,本地域名服务器查询自己的DNS缓存,查找成功则返回结果,否则依次向根域名服务器顶级域名服务器权限域名服务器发起查询请求,最终 返回IP地址给本地域名服务器

  4. 本地域名服务器将得到的IP地址返回给操作系统,同时自己也将IP地址缓存起来

  5. 操作系统将 IP 地址返回给浏览器,同时自己也将IP地址缓存起来

  6. 浏览器得到域名对应的IP地址

    拓展:优化====减少dns查找,dns预获取,延长dns缓存时间,使用cdn加速域名等

[4] TCP和HTTP的区别#

  • 首先建立一个TCP连接,需要经过三次握手的过程,握手的过程不包含任何的数据。而HTTP连接最显著的特点是客户端每次发送的请求服务器端都要做出响应,请求结束后,会主动释放连接,从建立链接到释放连接的过程就是一次连接。

  • 由于HTTP每次请求结束后都会自动释放连接,所以如果要保持客户端在线的状态,就要不断向服务器端发送连接请求,服务器端收到后,做出响应,表明知道客户端在线,如果服务器端长时间没有收到客户端请求,就认为客户端下线,如果客户端长时间没有收到服务器响应,就认为网络已经断开。而TCP连接一旦建立好,只要双方没发送断开链接的请求,连接就一直在。

  • TCP是传输层协议,HTTP是应用层协议,但是HTTP也是基于TCP的基础上工作的。TCP只是简单的建立链接,不涉及我们请求的数据,而HTTP是用来接发数据的

[4] TCP流量控制和拥塞控制#

![image-20241217122554109](/Users/guang/Library/Application Support/typora-user-images/image-20241217122554109.png)

  • 流量控制:控制发送方的发送速率,让接收方来得及接收数据,作用对象是发送端和接收端

  • 拥塞控制:前者控制点对点的通信量,后者考虑的是整个网络

    四种算法:①慢开始,②拥塞避免,③快重传,④快恢复

    慢开始和拥塞避免:首先会设置一个慢开始门限ssthresh状态变量,若窗口小于该门限值,使用快开始算法(二次函数),当窗口大于门限,则改用拥塞避免算法(一次函数),让窗口按线性规律增大,若发现网络拥堵,把慢开始门限设为当前出现拥塞时窗口的一半,窗口重新回到1,继续执行满开始算法

    快重传

    快重传解决的问题:个别报文段丢失,网络实际并未发生拥堵,但发送方没收到确认,就会产生超时,误认为是网络拥堵。

    快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认,使发送方及早知道有报文段没有到达对方,发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段,而不必继续等待重传计时器 到期。

    快恢复

    当发送方连续收到三个重复确认,就会把慢开始门限ssthresh减半,接着把拥塞窗口值设置为慢开始门限 ssthresh减半后的数值,然后开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大。

localstorage、sessionstorage统称为webstorage

①存储位置:localstorage、sessionstorage、cookie都存储在浏览器中,cookie会在每一次请求中携带,并可以设置过期时间,并在浏览器和服务器中来回传输,而localstorage、sessionstorage仅仅保存在浏览器本地;

②存储大小的不同:localstorage、sessionstorage可达5M,而cookie不能超过4k;

③数据有效期不同:localstorage永久保存,不能跨浏览器使用;sessionstorage关闭浏览器或者页面会被清理,刷新不会,不能跨页面交互;cookie过期时间之前都有效;

④作用域的不同:

⑤应用场景:cookie一般用来存储登陆信息,因为它依赖网络,所以只能存小东西;localstorage一般存储不经常修改的数据

[3] cookie 与 session#

由于HTTP协议是无状态的协议,需要用某种机制来识具体的用户身份,用来跟踪用户的整个会话。常用 的会话跟踪技术是cookie与session。

Cookie

cookie就是由服务器发给客户端的特殊信息,存储在客户端,每次向服务器发送请求携带cookie(放在请求头里),服务器分析cookie得到客户端特有信息,动态生成相应内容。(网站的登录界面中“请记住我” 这样的选项,就是通过cookie实现的)

Cookie工作流程:

  1. servlet创建cookie,保存少量数据,发送给浏览器。
  2. 浏览器获得服务器发送的cookie数据,将自动的保存到浏览器端。
  3. 下次访问时,浏览器将自动携带cookie数据发送给服务器。

session (sessionID存储在Cookie中)

浏览器请求服务器访问web站点时,服务器先检查客户端请求是否带有sessionID,如果包含则说明以前创建过session,直接安装sessionID把该session检索出来使用,如果不包含则创建一个session,并生成一个相关联独一无二的sessionID存放到cookie中,并返回给客户端保存。之后每一次请求都会带着sessionID,服务器根据这个sessionID就可以找到对应session,以此来达到共享数据。

Cookie和Session的区别

1、作用范围不同:Cookie 保存在客户端(相当于浏览器),Session 保存在服务器端

2、有效期不同:Cookie 可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般失效时间较短,客户端关闭或者 Session 超时都会失效。

3、隐私策略不同:Cookie存储在客户端,容易被窃取;Session 存储在服务端,安全性相对 Cookie 要好一些。

4、存储大小不同:单个 Cookie 保存的数据不能超过 4K;对于 Session 来说存储没有上限,但出于 对服务器的性能考虑,Session 内不要存放过多的数据,并且需要设置 Session 删除机制。

[3] OSI七层模型 和 TCP/IP五层模型#

  • 应用层:为应用程序提供交互服务。在互联网中的应用层协议很多,如域名系统DNS、HTTP协 议、SMTP协议等。
  • 传输层:负责向两台主机进程(端到端)之间的通信提供数据传输服务。传输层的协议主要有传输控制协议 TCP和用户数据协议UDP。
  • 网络层:选择合适的路由和交换结点,确保数据及时传送。主要包括IP协议。
  • 数据链路层:在两个相邻节点之间传送数据时,数据链路层将网络层交下来的 IP 数据报组装成 帧,在两个相邻节点间的链路上传送帧。
  • 物理层:实现相邻节点间比特流的透明传输,尽可能屏蔽传输介质和物理设备的差异。
  • 七层的话 还有 会话层和表示层

[3] http2.0和http3.0#

[2] 网络攻击XSS CSRF#

Xss(cross-site scripting) 攻击:全称跨站脚本攻击,通过向某网站写入 js 脚本或插入恶意 html 标签来实现攻击,如论坛中放一个钓鱼链接获取cookie信息,或者加入恶意表单,获取信息

  • 防范方法
    • 内容安全策略:①入参字符过滤,②出参进行编码,③入参长度限制

CSRF (Cross Site Request Forgery)攻击:跨站请求伪造。CSRF 攻击是攻击者借助用户的 Cookie 骗取服务器的信任,以用户名义伪造请求发送给服务器。如:在请求的 url 后加入一些恶意的参数

  • 防范方法
    • Referer Check:在http请求头中有一个字段叫做 Referer, 它记录了该 HTTP 请求的来源地址。通过 Referer Check, 可以检查是否来自合法的 “源”。
    • 添加 token 验证:在 HTTP 请求中以参数的形式加入一个随机产生的 token,并在服务器端建立一个拦截器来验证这个 token,若请求无 token 或者 token 不正确,则认为可能是 CSRF 攻击而拒绝该请求。
    • 验证码:验证码会强制用户必须与应用进行交互,才能完成最终请求,但是也不能给网站所有的操作都加上验证码,所以只能作为防御 CSRF 的一种辅助手段,而不能作为最终的解决方案

计算机网络
https://huiguang.site/posts/cscyber/
作者
冼慧光
发布于
2021-12-17
许可协议
CC BY-NC-SA 4.0