这是一份关于计算机网络的面试向准备笔记

Http是一个无状态协议，不记录客户端的相关信息

URL 和 URI 的区别

  • URI: 统一资源标识符，用来标识资源，就像身份证号一样。
  • URL: 统一资源定位符， 是URI 的子集，既可以用它来标识资源，也可以定位资源。可以理解成住址

所以不论是用定位的方式还是用编号的方式，我们都可以唯一确定一个人，都是URl的一种实现，而URL就是用定位的方式实现的URI。

Http 和 Https 的区别

  • Http：80端口； Https: 443 端口
  • Http，超文本传输协议，明文传输。
    Https，运行在SSL上，添加了加密、认证机制，安全可靠。
  • Https 需要更大的内存和CPU的开销
  • Https 需要购买认证证书。
加密算法

  • 对称加密（速度快）
    加密和解密采用相同的密钥。 如： DES， RC2， RC4

  • 非对称加密（更安全）
    由两部分：公钥、私钥。如果用公钥加密，需要使用私钥才能解密。如：RSA

  • CA 认证证书
    第三方数字签名认证机构，为了确定https中服务器发送的公开密钥没有被篡改，因此会先发送给可信的第三方机构进行签名，客户端使用机构的公开密钥进行签名的认证，用来保证服务器公开密钥的可靠性。
  • 数字签名、报文摘要的原理
    发送者用私钥进行签名，接收者用公钥进行验证。

Https的连接过程

https

第一次握手，交换基本信息

  • 客户端向服务端发送一个招呼报文（hello），包含自己支持的SSL版本，加密算法等信息。
  • 服务端回复一个招呼报文（hi）包含自己支持的SSL版本，加密算法等信息。
  • 服务端发送自己经过CA认证的公开密钥
    • 服务端向CA认证机构发送自己的公开密钥（FPkey）
    • CA认证机构使用自己的私有密钥给FPkey加上签名返回给服务端
  • 服务端发送结束招呼的报文，SSL第一次握手结束。

第二次握手，确定加密策略

  • 客户端使用FPkey对自己的随机密码串（Ckey）进行加密并发送给服务端
    • 客户端首先使用CA的公开密钥对FPkey的签名进行认证，确认密钥未被替换
  • 客户端发送提示报文，后续报文将用Ckey进行加密。
  • 客户端发送finished报文，表示该次发送结束
    • 后续是否通信取决于客户端的finished报文能否被服务端成功解密
  • 服务端发送提示报文，表示他之后的报文也会用Ckey进行加密
  • 服务端发送finished报文。至此SSL握手结束，成功建立SSL连接。

SSL 建立成功，开始数据传输

  • 客户端开始发送http请求报文
    • 建立Tcp连接，开始传输数据
  • 服务端发送http回复报文

断开连接

  • 客户端发送断开连接报文，并断开Tcp连接

非对称加密算法用于在握手过程中加密生成的密码；对称加密算法用于对真正传输的数据进行加密；HASH算法用于验证数据的完整性。

访问http如何自动转换为https

用户在地址栏输入地址，默认以http访问，此时服务器发送一个状态码：Status Code: 307 Temporarily Redirect
状态代码：307，暂时重定向。其实也不一定是307，有些网站是302。
3xx状态码就是告诉客户端，请求的URL不存在，需要去访问另外一个URL。服务器把所有的HTTp流量跳转到HTTPS

一种更安全的机制：
HSTS，web安全协议，核心是一个HTTP响应头，强制拒绝用户的不安全链接，浏览器识别后自动访问https

HTTPS 中间人拦截过程

中间人拦截过程发生在第一个部分，拦截服务端返回的公钥，构建一对新的密钥伪装成公钥发送给客户端。然后拿到客户端的随机数，再用服务端的公钥进行加密，将密钥发送给服务端。
https中间人拦截

常见的http方法

  • Get：向服务器请求资源
  • POST：向服务器提交资源，比如提交表单，订单等。不是幂等的。多次请求可能有副作用。
  • PUT：向服务器提交资源，但是是幂等的，后面的请求会覆盖原来的请求。用于修改服务器上的资源
  • HEAD：请求http响应头。
  • DELETE：请求服务器删除某资源

GET与POST的区别

  • HTTP GET 方法请求指定的资源。使用 GET 的请求应该只用于获取数据。
  • get是从服务器上获取数据，post是向服务器传送数据
  • HTTP POST 方法 发送数据给服务器. 请求主体的类型由 Content-Type 首部指定.
  • PUT 和POST方法的区别是,PUT方法是幂等的：连续调用一次或者多次的效果相同（无副作用）。连续调用同一个POST可能会带来额外的影响，比如多次提交订单。

GET的语义是请求获取指定的资源。GET方法是安全、幂等、可缓存的（除非有 Cache-ControlHeader的约束）, GET方法的报文主体没有任何语义。POST的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST不安全，不幂等，（大部分实现）不可缓存。

常见状态码

  • 2xx：操作成功. eg: 200 OK
  • 3xx: 重定向. 301 永久重定向;302 Found, 用于重定向; 307 暂时重定向
  • 4xx: 客户端错误. 400 bad request; 401 unauthorized; 403 forbidden; 404 not found;
  • 5xxx: 服务端错误. 500 服务器内部错误, 501服务器不可用, 502 bad gatewat, 503 Service Unavailable 服务器暂时超负载或者停机维护.

TCP

TCP是一种面向连接的单播协议。
所谓连接，即双方各自保存一份对方的信息，如ip地址，端口等等。
可靠的、面向连接的、字节流、传输层的协议

TCP 采用三次握手建立连接，四次挥手断开连接。

一些概念

  • ACK acknowledge
    当TCP接收到另一端的数据时，它会发送一个确认，但这个确认不会立即发送，一般会延迟一会儿。ACK是累积的，一个确认字节号N的ACK表示所有直到N的字节（不包括N）已经成功被接收了。这样的好处是如果一个ACK丢失，很可能后续的ACK就足以确认前面的报文段了。

  • ACK —— 确认，使得确认号有效。

  • RST —— 重置连接（经常看到的reset by peer）就是此字段搞的鬼。

  • SYN —— 用于初如化一个连接的序列号。

  • FIN —— 该报文段的发送方已经结束向对方发送数据。

  • ISN —— Initial Sequence Number

一个完整的TCP连接是双向和对称的，数据可以在两个方向上平等地流动。

具体实现

三次握手 - 建立连接
  • 客户端发送一个SYN段，并指明客户端的初始序列号
  • 服务端发送自己的SYN段作为应答，为了确认客户端的SYN，将ISN(c)+1作为ACK数值
  • 为了确认服务器端的SYN，客户端将ISN(s)+1作为返回的ACK数值。
    三次握手
四次挥手 - 断开连接
  • 客户端发送一个FIN段，并包含一个希望接收者看到的自己当前的序列号K. 同时还包含一个ACK表示确认对方最近一次发过来的数据。
  • 服务端将K值加1作为ACK序号值，表明收到了上一个包。这时上层的应用程序会被告知另一端发起了关闭操作，通常这将引起应用程序发起自己的关闭操作。
  • 服务端发起自己的FIN段，ACK=K+1, Seq=L
  • 客户端确认。ACK=L+1

四次挥手

why 三次握手和四次挥手

  • 三次握手
    简言之，是为了判断双方的接收和发送能力都正常从而建立正常的连接。
    每个端只能知道自己成功发送/或接收数据，并不能知道对方的情况，所以需要三次握手确认连接正常建立。

    其实每次收到网络包的一方至少是可以得到：对方的发送、我方的接收是正常的。

  • 四次挥手
    TCP连接是双向传输的对等的模式，就是说双方都可以同时向对方发送或接收数据。当有一方要关闭连接时，会发送指令告知对方，我要关闭连接了。这时对方会回一个ACK，此时一个方向的连接关闭。但是另一个方向仍然可以继续传输数据，等到发送完了所有的数据后，会发送一个FIN段来关闭此方向上的连接。接收方发送ACK确认关闭连接。注意，接收到FIN报文的一方只能回复一个ACK, 它是无法马上返回对方一个FIN报文段的，因为结束数据传输的“指令”是上层应用层给出的。

TCP与UDP的区别

  • TCP是面向连接的， UDP是无连接的（只管发送）
  • TCP是可靠的， UDP不可靠（UDP接收方收到报文后，不需要给出任何确认）
  • TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多；
  • TCP是面向字节流的，UDP是面向报文的
    面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。
  • TCP有拥塞控制机制，UDP没有。网络出现的拥塞不会使源主机的发送速率降低，这对某些实时应用是很重要的，比如媒体通信，游戏
  • TCP Heaader开销（20字节）比UDP开销（8字节）要大
  • UDP 的主机不需要维持复杂的连接状态表

什么时候选择TCP，什么时候选UDP？

对某些实时性要求比较高的情况，选择UDP，比如游戏，媒体通信，实时视频流（直播），即使出现传输错误也可以容忍；其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失

TCP如何保证传输的可靠性

  • 数据包校验
  • 对失序数据包重新排序（TCP报文具有序列号）
  • 丢弃重复数据
  • 应答机制：接收方收到数据之后，会发送一个确认（通常延迟几分之一秒）；
  • 超时重发：发送方发出数据之后，启动一个定时器，超时未收到接收方的确认，则重新发送这个数据；
  • 流量控制：确保接收端能够接收发送方的数据而不会缓冲区溢出

TCP的流量控制（接收方原因）

如果接收方的读取速率远不及发送方的发送速率，接收方缓存很容易用光。

双方各自维护一个“接收窗口”的变量。用以表示空闲空间的大小，这个变量在动态改变。

如果接收方没有能力接收数据，就会将接收窗口设置为0，这时发送方必须暂停发送数据，但是会启动一个持续计时器(persistence timer)，到期后发送一个大小为1字节的探测数据包，以查看接收窗口状态。如果接收方能够接收数据，就会在返回的报文中更新接收窗口大小，恢复数据传送。

TCP的拥塞控制（网络原因）

tcp 的拥塞控制 是端到端的拥塞控制，而不是网络辅助的拥塞控制。因为ip层并不向端系统提供网拥塞反馈。

维护一个新变量，拥塞窗口。
发送方的流量速率不能超过 拥塞窗口 和 接收窗口 中的最小值

  • 丢包意味着拥塞发生， 应降低发送速率

  • ACK信号可以认为是正常到达接收方，可以增加发送方的速率

  • 带宽检测。发送速率在正常时持续提高，直到发生拥塞，再降低继续探测。

  • MSS Maximum Segment Size，最大报文段，收发双方协商通信时每一个报文段所能承载的最大数据长度

  • RTT ，Round-Trip Time，往返时延

慢启动（指数级增加）

先把拥塞窗口（congestion window）设置为一个最大报文段MSS的数值，每收到一个新的确认报文之后，就把拥塞窗口增加一倍MSS(1, 2, 4, 8, ….)。这样每经过一个传输轮次（或者说是每经过一个往返时间RTT），拥塞窗口的大小就会加倍

直到发生掉包，设置拥塞窗口为1， 并且设置ssthresh (slow start threshold)为拥塞窗口的一半大小，重新开始慢启动
或者当窗口大小 接近 ssthresh时，进入拥塞避免阶段。
或者检测到三个 冗余的 ACK 进入快速恢复阶段

拥塞避免（线性增长）

这个阶段是在试探上限。

即每经过一个传输轮次只增加1MSS

直到 超时、丢包，设置拥塞窗口为1MSS， 并且设置ssthresh (slow start threshold)为拥塞窗口的一半大小，重新开始慢启动

快重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快速恢复

当发送方连续收到三个重复确认时，就把慢开始门限ssthresh设置为 1/2 拥塞窗口，然后执行拥塞避免算法。

不执行慢开始算法的原因：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方认为现在网络可能没有出现拥塞。

也有的快重传是把开始时的拥塞窗口cwnd值再增大一点，即等于 ssthresh + 3*MSS 。这样做的理由是：既然发送方收到三个重复的确认，就表明有三个分组已经离开了网络。这三个分组不再消耗网络的资源而是停留在接收方的缓存中。可见现在网络中减少了三个分组。因此可以适当把拥塞窗口扩大些。

另一种阐述：

1.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络。

2.再收到重复的ACK时，拥塞窗口增加1。

3.当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。

一些问题

  • HTTP可以使用UDP吗？
    HTTP不可以使用UDP，HTTP需要基于可靠的传输协议，而UDP不可靠

参考文章：
访问http如何自动转换为https

https://zhuanlan.zhihu.com/p/79367346

https://www.jianshu.com/p/8b9bb785eece
https://www.zhihu.com/question/28586791

“三次握手，四次挥手”你真的懂吗?
“计算机网络”

TCP与UDP的区别
[TCP拥塞控制——快重传和快恢复] (https://blog.csdn.net/qq_36953135/article/details/77506009)