M3 计算机网络知识点汇总（1）

目录

00 总体概述

0-1 OSI模型

OSI模型(Open System Interconnection Reference Model)分为七层：分别是应用层，表示层，会话层，传输层，网络层，数据链路层，物理层。

  • 高三层是资源子网
  • 底三层为通信子网

物理层：

  • 传输单位：bit(比特)
  • 目标：透明比特流传输，
  • 协议主要是硬件协议，约定信号的高低电平，比如EIA协议，嵌入开发中的I2C，串口协议也算是类似的物理层协议。 RJ45 、 CLOCK 、 IEEE802.3
  • 典型设备：中继器，集线器，网关

数据链路层（子网内部，传输依赖mac地址，点到点通信，点指的是IP地址或者硬件地址）：

为什么需要IP地址与硬件地址2套地址？ IP地址是需要分配，硬件地址是绝对的。

  • 传输单位：数据帧
  • 目标：将网络的IP数据封装为数据帧，提供成帧，差错控制（物理信道干扰，数据帧信息的变质），流量控制（协调2个节点之间的传输速率）和传输管理等功能。
  • 典型协议：PPP 、 FR 、 HDLC 、 VLAN 、 MAC
  • 典型设备：网桥，交换机（可以看成多端口网桥）
    • 网桥：连接两个局域网的一种存储/转发设备，它能将一个大的LAN分割为多个网段，或将两个以上的LAN互联为一个逻辑LAN，使LAN上的所有用户都可访问服务器。

网关，网桥，路由器，交换机的区别

网络层（通信子网之间，传输依赖IP地址）

  • 传输单位：数据报（分组）
  • 设计目的：关键是路由选择（路由算法），此外实现流量控制（协调传输速率），拥塞控制（网络分组数量超出处理能力，需要大量丢弃分组），差错控制（对分组进行奇偶校验），国际互联
  • 典型协议： IP(Internet Protocol) 、 ICMP((Internet Control Message Protocol)) 、 ARP(Address Resolution Protocol,局域网内通过IP获取MAC地址) 、 RARP(Reverse Address Resolution Protoca) 、 OSPF 、 IPX 、 RIP 、 IGMP(Internet Group Management Protocol)
    • ICMP协议的2个应用：ping检测网络联通性，Tracert利用TTL追踪包的传输过程，用于分析丢包以及网络时间延迟。
    • ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证通信的顺利进行。
    • RARP协议：允许局域网的物理机器从网关服务器的 ARP 表或者缓存上请求其 IP 地址
    • IGMP(Internet Group Management Protocol):就是组播路由协议，用于知道组播组成员协议
    • 组播的概念：源计算机一次发送的单个分组能够抵达用一个组地址表示的若干台主机(采用UDP，TCP是面向连接的，适合一对一，不适合一对多，需要路由器支持，设定组播IP，分组中协议为2)

ARP协议特点：不能穿越路由器，不能被转发到其它广播域

IP的头部：

ICMP协议两个典型的应用你都会用了吗？

ARP协议详解

RARP协议

(网络层)IP 协议首部格式与其配套使用的四个协议(ARP,RARP,ICMP,IGMP)

传输层（端到端，2个进程的端口之间）：

  • 传输单位：TCP报文与UDP报文
  • 目的：保证主机间2个进程的可靠通信，支持复用（多个进程共享）与分用（分别向多个进程提供服务）功能
  • 典型的协议：TCP(Transmission Control Protocol), UDP(User Datagram Protocol）

会话层

  • 目的：基于传输层为表示层提供增值服务。
  • 典型的协议：NFS(网络文件协议) 、 SQL 、 NETBIOS 、 RPC(Remote Procedure Call Protocol:远程调用协议，进程之间的远程调用 )
    • RPC框架（比如，CORBA、RMI、Web Services、RESTful Web Services等等）（微服务常用的协议）

关于RPC协议的通俗理解

RPC、SQL、NFS属于OSI的哪一层

表示层

  • 目的：主要提供数据的编码，压缩，加/解密。

  • 典型的协议： JPEG 、 MPEG 、 ASII （都是一些数据的格式）

应用层协议

  • 目的：为各种不同的应用定制的协议
  • 典型的协议： FTP 、 DNS(Domain Name System,域名到IP的转换) 、 Telnet 、 SMTP 、 HTTP 、 WWW 、DHCP
    • Telnet: telecom munication net work protocol：Telnet经常用于测试网络及端口占用情况
    • DHCP(Dynamic Host Configuration Protocol):基于UDP的应用层协议，用于配置主机IP

DNS详解

网络协议篇之DHCP协议（一）—— DHCP协议基础

0-2 TCP/IP模型（原始的是四层）

TCP/IP模型与OSI模型的分层关系

  • 网络接口层包含物理层与数据链路层
  • 应用层包含有会话层，表示层，应用层。

0-3 经典的五层协议

0-4 网络七层对应的协议

- 物理层： RJ45 、 CLOCK 、 IEEE802.3 （中继器，集线器，网关）

- 数据链路： PPP 、 FR 、 HDLC 、 VLAN 、 MAC （网桥，交换机）

- 网络层： IP 、 ICMP 、 ARP 、 RARP 、 OSPF 、 IPX 、 RIP 、 IGRP 、 （路由器）

- 传输层： TCP 、 UDP 、 SPX

- 会话层： NFS 、 SQL 、 NETBIOS 、 RPC

- 表示层： JPEG 、 MPEG 、 ASII

- 应用层： FTP 、 DNS 、 Telnet 、 SMTP 、 HTTP 、 WWW

01 TCP三次握手和四次挥手

  • 源端口与目的端口（各占2个字节）
  • 序号/确认号（各占4个字节): 确认号 = 最近接受的发送发包的序号+1，这样就是告诉对方收到了哪些报文。
  • 确认号(4个字节)
数据偏移 保留位 URG ACK PSH RST SYN FIN 窗口
4位 16位

  • 确认位ACK 只有当ACK=1时确认号字段才有效。当ACK 0时，确认号无效。 TCP规定，在连接建立后所有传送的报文段都必须把ACK置1

  • 同步位SYN同步SYN=1表示这是一个连接请求或连接接收报文。

  • 终止位FIN (Finish)用来释放一个连接。FIN=1表明此报文段的发送方的数据已发送完毕，并要求释放传输连接。

  • 窗口字段占2 字节。它指出了现在允许对方发送的数据量，接收方的数据缓存空间是有限的，故用窗口值作为接收方让发送方设置其发送窗口的依据，单位为字节

1.1 TCP三次握手和四次挥手的过程

三次握手过程：

step1: 客户机向服务器发送连接请求报文，请求报文有以下特点：

  • 没有应用层数据
  • TCP报文段头部的同步位(SYN)被设置为1
  • 报文起始序号被设为x,

step2: 服务器收到了请求报文，同意建立连接，为这个连接分配缓存与变量，并发送确认报文，确认报文有以下特点：

  • 同步位与确认位被设置为1
  • 确认号为请求报文的序号+1（x+1）
  • 确认报文随机产生起始序号y.

step3: 客户机收到来自服务器的确认报文后才开始分配连接的缓存与变量，发送确认报文具有以下特点：

  • 确认位设置为1
  • 序号字段自增（x+1）
  • 确认号为服务器的确认报文序号+1 (y+1)

三次握手的总结：

  • 同步---->确认+同步(分配资源，半连接状态)----> 确认（分配资源） (事实上只有后面的连接建立，ACK都是1)
    • 由于服务器先于客户机分配变量，这种缺陷会被用于TCP SYN 泛洪泛洪攻击,本质是让服务器建立大量半连接耗尽服务器资源。
    • 同步位只在前二次回挥手才会被用到
四次挥手过程

step1:客户机发送连接释放报文，报文中FIN标志位被设为1，此后客户机将不会向服务器发送数据。

  • 当发送FIN=1的报文时，发送FIN的一端就不能发送数据。

step2: 服务器接受连接释放报文，发送确认报文，此时TCP处于半关闭状态即客户机到服务器的通道断了，但是服务器发送给客户机数据时，客户机依旧要接受。

step3:服务器发送完确认报文后，如果没有数据发送，那么直接发送FIN=1的连接释放报文。（表明服务器不会再发送数据）

step4:客户机发送确认报文（此时ACK字段竟然还是1），并等待2MSL后，客户机释放资源关闭连接。

四次挥手总结

  • 终止---->确认----->终止--->确认----等待2MSL---->关闭
  • 四次挥手的过程报文段ACK都为1
  • 四次挥手第一次和第三次的FIN=1

1.2 为什么TCP建立连接需要三次握手,断开连接需要四次挥手

第三次握手原因：为了防止已失效的连接请求报文段（网络原因造成报文很长时间才到服务器）造成资源的浪费，服务器可以设置一个时间阈值，当超过这个阈值还是没有第三次握手，则放弃已经建立的半连接。

四次挥手原因（为什么不是三次挥手）：

  • 数据的传输是双向的，单方向停止发送需要数据需要请求与确认2个流程，双向则是需要四个流程（第四次挥手的重要性可以看1.3）。
  • 另外就是服务端由于被动关闭，可能存在一些数据没有发送完，因此需要等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)（第2，3次挥手为什么不合并。）。

为什么需要三次握手四次挥手

为什么需要3次握手，4次挥手（好）

1.3 TCP四次挥手为什么有Time-Wait过程，要等待2MSL

2个原因：

  • 确保服务器能够收到确认包，从而关闭连接，留有等待的时间便于重新发送确认包（waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request.）（表面原因）。
    • ACK从A到B最多经过1MSL，超过这个时间B会重发FIN，B重发的FIN最多经过1MSL到达A，如果B重发了FIN，且网络没有故障(重发的FIN被丢弃或错误转发)，那么A一定能在2MSL之内收到该FIN，因此A只需要等待2MSL。
    • Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”
  • 确保当前连接所关联的网络数据包都从网络中消失（从而保证下一个使用了相同四元组的tcp连接不会被上一个连接的报文所干扰(本质原因)）
    • 如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的TCP报文可能与新TCP连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的TCP连接的活跃报文全部死翘翘，2MSL时间可以满足这个需求（尽管非常保守）！
    • 这2个MSL中的第一个MSL是为了等自己发出去的最后一个ACK从网络中消失，而第二MSL是为了等在对端收到ACK之前的一刹那可能重传的FIN报文从网络中消失

为什么TCP4次挥手时等待为2MSL？

为什么tcp的TIME_WAIT状态要维持2MSL(好文)

1.4 TCP第三次握手可以传输数据吗

可以传输

1.5 如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
参考

2. TCP和UDP的区别（从数据头部思考）

  • 长度是UDP数据报的长度，最小为8个字节。

二者区别：

从2个数据头的格式来考虑（3点）：

  • TCP相比UDP需要建立连接(SYN,FIN)（面向连接VS无连接）

  • 输有序(序号)，不丢失（重传）且无重复（ACK），UDP则可能丢包，顺序错乱（可靠VS不可靠）

  • TCP 是面向字节流的，UDP 是基于数据报的

二者应用场景：

  • TCP应用场景：
    效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。
  • UDP应用场景：
    效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

TCP和UDP的区别

3. TCP的可靠传输

3.1 TCP如何确保可靠性传输（联想TCP头部，四个机制）？

采用了校验（无差错），序号（有序性），重传（不丢失），确认（不重复）共四个主要机制保证。

校验：

序号：保证数据能有序提交给应用层，TCP把数据看成一个无结 构但是有序的字节流，而序号是建立在传送的字节流之上，而不是建立在报文段之上。

确认：TCP首部的确认号是期望收到对方的下一个报文段的数据的第一个字节的序号。** TCP默认使用累计确认，即TCP只确认数据流中至第一个丢失字节为止的字节。（注意一个TCP报文中可能有多个字节的数据，因此TCP的序号并非是随着报文段的增加而递增）

重传：

有两种事件会导致TCP对报文段进行重传:超时和冗余ACK.

1)超时
TCP每发送一个报文段，就对这个报文段设置一次计时器。只要计时器设置的重传时间到期但还没有收到确认，就要重传这一报文段。
记录一个报文段发出的时间，以及收到相应确认的时间，这两个时间之差叫做报文段的往返时间(RTT)，超时计时器设置的超时重传时间(RTO)应略大于上面得出的加权平均往返时间RTTs。

2)冗余ACK(冗余确认)
超时触发重传存在的一个问题就是超时周期往往太长。冗余ACK就是再次确认某个报文段的ACK，而发送方先前已经收到过该报文段的确认TCP规定每当比期望序号大的失序报文段到达时，发送一个冗余ACK，指明下一个期待字节的序号[RFC 1122, RFC2581]。（理解失序报文）

3.2 TCP的拥塞控制（四个算法）

拥塞控制目的：防止过多的数据注入网络中，避免网络中的路由器或链路过载。

拥塞控制的四个典型措施：慢开始、 拥塞避免、快重传、快恢复。

这四个算法的核心策略就是去控制接受窗口以及拥塞窗口这两个窗口的大小。

  • 接收窗口rwnd：接收方根据目前接收缓存大小所许诺的最新的窗口值，反映了接收方的容量。由接收方根据其放在TCP报文的首部的窗口字段通知发送方
  • 拥寒窗口cwnd：发送方根据自己估算的网络拥塞程度而设置的窗口值，反映了网络的当前容量。只要网络出现拥塞，拥塞窗口就减小一些，以减少注入网络中的分组数
  • 发送窗口：发送窗口的上限值 = Min[rwnd，cwnd]
    • 一些场景下，接受方的缓存比较大，此时发送窗口大小完全取决于拥塞窗口
3-2-1 慢开始

使用慢开始算法后，每经过一个传输轮次(即往返时延RTT),拥塞窗口cwnd就会加倍，即cwnd的大小量指数形式增长。这样慢开始一直把拥塞窗口cwnd 增大到一个规定的慢开始门限ssthresh(阈值)，然后改用拥塞避免算法

3-2-2 拥塞避免(线性加，乘法减)

​ 发送端的拥塞窗口cwnd每经过一个往返时延RTT就增加一个MSS的大小，而不是加倍，使cwnd按线性规律缓慢增长(即加法增大)，而当出现一次超时(网络拥塞)时，则令慢开始门限ssthresh等于当前cwnd的一-半( 即乘法减小)。

  • MSS: Maxitum Segment Size 是TCP数据包每次能够传输的最大数据分段，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值（MSS参考）
  • 乘法减少使得当网络中出现拥塞时，能够快速降低阈值，从而避免大量分组进入到网络中。

根据cwnd的大小执行不同的算法，可归纳如下

  • 当cwnd < ssthresh时，使用慢开始算法。

  • 当cwnd > ssthresh时，停止用慢开始算法而改用拥塞避免算法。

  • 当cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法(通常做法)。

3-3-3 快重传（利用重传机制的冗余ACK）

当发送方连续收到三个重复的ACK报文时，直接重传对方尚未收到的报文段，而不必等待那个报文段设置的重传计时器超时.

3-3-4 快恢复（配合快重传一起使用）

​ 当发送端收到连续三个冗余ACK(即重复确认)时，就执行“乘法减小”算法，把慢开始门限sthresh设置为出现拥塞时的cwnd的一半。与慢开始(慢开始算法将拥塞窗口cwnd设置为1)不同之处是它把cwnd的值设置为慢开始门限ssthresh改变后的数值，然后开始执行拥塞避免算法(“加法增大”)，使拥塞窗口缓慢地线性增大。

3.3 TCP传输通信时,客户端突然断开连接,服务端如何判断？

基本的策略：服务端反复发送数据分组给客户端，如果一段时间内没有回应，则服务端主动关闭连接。这种思想在传输层与应用层都可以去实现，比如下面2种机制

  • Keep alive机制是很多的TCP实现提供的一种机制，适用于清除死亡时间比较长的连接。
  • heart beat机制需要在应用层实现。一个简单的heart-beat实现一般测试连接是否中断采用的时间间隔都比较短，可以很快的决定连接是否中断。并且，由于是在应用层实现，因为可以自行决定当判断连接中断后应该采取的行为，而keepalive在判断连接失败后只会将连接丢弃

TCP通讯客户端怎样判断与服务器端断开,该如何处理

3.4 TCP的端口时为了区分什么

TCP设计的目的就是为了提供端到端的传输，端是指计算中的应用程序，端口号是为了区分同一台计算上不同的应用程序。

3.5 TCP的流量控制与滑动窗口关系？

流量控制

  • 本质是速度匹配服务(匹配发送方的发送速率与接收方的读取速率)，避免双发在传输的过程缓存区溢出。
  • TCP的流量控制是基于滑动窗口协议。
    • 基本思想：1）发送方根据当前缓存的大小，估计自己的接受窗口。2）在TCP头部设置窗口字段，将信息传递给接受方。3）接受方参考发送的接受窗口以及当前自己估计的拥塞窗口来确定最终发送窗口。

流量控制与拥塞控制的共同点与不同点

  • 共同点：都是通过调节速率达到控制目的
  • 不同点：流量控制面向端到端，拥塞控制是从网络整体考虑。

TCP的流量控制是基于

4. 常见的HTTP状态码

常见的HTTP状态码(HTTP Status Code，非常全，强烈推荐)

4-1 状态码的功能划分

状态码 功能
1XX 通知，1XX系列响应代码仅在与HTTP服务器沟通时使用。
2XX 成功，2XX系列响应代码表明操作成功了
3XX 重定向，3XX系列响应代码表明：客户端需要做些额外工作才能得到所需要的资源。它们通常用于GET请求。他们通常告诉客户端需要向另一个URI发送GET请求，才能得到所需的表示。那个URI就包含在Location响应报头里。
4XX 客户端错误：这些响应代码表明客户端出现错误。不是认证信息有问题，就是表示格式或HTTP库本身有问题。客户端需要自行改正
5XX 服务端错误：响应代码表明服务器端出现错误。一般来说，这些代码意味着服务器处于不能执行客户端请求的状态，此时客户端应稍后重试。有时，服务器能够估计客户端应在多久之后重试。并把该信息放在Retry-After响应报头里。

常见的http状态码

4-2 常见的http状态码

状态 功能
200（“OK”） 请求成功。一般用于GET与POST请求
400("Bad Request") 客户端请求的语法错误，服务器无法理解
500("Internal Server Error") 服务器内部错误，无法完成请求
301("Moved Permanently") 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
404("Not Found") 和410("Gone") 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
409("Conflict") 当客户端试图执行一个”会导致一个或多个资源处于不一致状态“的操作时，发送此响应代码(服务器完成客户端的PUT请求后可能返回此代码，服务器处理请求时发生了冲突)
304(Not Modified) 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源(这个状态码的目的通常是告诉浏览器可以使用自己缓存的信息)

5. HTTP（HyperText Transfer Protocol ）报文

定义：HTTP defines how Web clients request Web pages from Web servers and how servers transfer Web
pages to clients.

5.1 HTTP请求报文和响应报文的组成？

5.1.1 请求报文的组成

总的组成分为3个部分，分别是请求行，头部，主体

  • 请求行：包括请求方法|资源定位信息|所使用的http版本（the method field| the URL field|and the HTTP version field）

    • 请求方法(五种)：GET(最常使用的方法,请求的资源通过URL指定，比如上图中请求的资源就是page.html), POST, HEAD, PUT, and DELETE

  • 首部行：包含有主机信息，连接状态，用户代理，接受语言等信息

    • 明确请求的资源对象所在的host，（specifies the host on which the object resides，the information
      provided by the host header line is required by Web proxy caches ）

    • 用户代理：This header line is useful because the server can actually send different versions of the same object to different types of user agents. (Each of the versions is addressed by the same URL

  • 主体(entity body）：GET方法这部分为空，POST方法这部分提交用户填写的信息

    • The entity body is empty with the GET method, but is used with the POST method. An HTTP
      client often uses the POST method when the user fills out a form—for example, when a user provides search words to a search engine. With a POST message, the user is still requesting a Web page from the server, but the specific contents of the Web page

注意点：用户并非只能通过POST方法提交form信息，可以通过GET方法将form信息封装到请求行中的URL中。

实例：if a form uses the GET method, has two fields, and the inputs to the two fields are monkeys and bananas , then the URL will have the structure www.somesite.com/animalsearch?monkeys&bananas . In your day-to-day Web surfing, you have probably noticed extended URLs of this sort.

Head(开发者调试用),PUT（上传资源到server）,DELETE（删除server资源）三种方法的应用：

  • The HEAD method is similar to the GET method. When a server receives a request with the HEAD
    method, it responds with an HTTP message but it leaves out the requested object. Application
    developers often use the HEAD method for debugging.
  • The PUT method is often used in conjunction with Web publishing tools. It allows a user to upload an object to a specific path (directory) on a specific Web server. The PUT method is also used by applications that need to upload objects to Web servers.
  • The DELETE method allows a user, or an application, to delete an object on a Web server.
5.1.2 回复报文的组成，

​ 三个部分组成，分别是状态行，头部，主体

  • 状态行：
    • 协议类型及版本号
    • 状态码(404,500之类的)
    • 状态码的文字描述
  • 头部
5.1.3 http报文的组成总结

http报文结构为：

  • 起始行（请求报文与接受报文在起始行有所区分）
    对报文进行描述
  • 头部：附加信息（cookie，缓存信息等）与缓存相关的规则信息，均包含在header中
    例如：Content-Length（主体长度），Content-Type（主体类型）等。
  • 主体：HTTP请求真正想要传输的部分
    包含数据的主体部分

http的请求报文，强力推荐

5.2 HTTP请求报文包含哪些方法, GET和POST的区别？

1.OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
2.HEAD
向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
3.GET
向特定的资源发出请求。它本质就是发送一个请求来取得服务器上的某一资源。资源通过一组HTTP头和呈现数据（如HTML文本，或者图片或者视频等）返回给客户端。GET请求中，永远不会包含呈现数据。
4.POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
5.PUT
向指定资源位置上传其最新内容
6.DELETE
请求服务器删除Request-URL所标识的资源
7.TRACE
回显服务器收到的请求，主要用于测试或诊断
8.CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

GET与POST区别：

其实他们的本质区别是GET是从服务器上请求数据，而POST是向服务器发送数据

  • 使用上的本质区别：GET满足幂等性，即get请求不会改变服务器的状态，同一GET的多次请求的结果应该相同，而POST则可能会改变服务器数据，因此如果发送的请求会对服务器数据产生影响，采用Post。
  • GET方法的数据参数是暴露在起始行的URL中的，而POST方法的数据参数是在报文主体中的。
  • GET方法相对来说没有POST安全，因为它的数据参数可以直接从URL中获取，但是GET的效率更高。
  • GET方法的数据参数大小有一定的限制（1024）（原因也是因为它的数据参数是放在URL中的），而POST对数据大小是没有限制的。
关于代理服务器的原理及用法

6. HTTP和HTTPS的区别

为什么需要https?

实际中http在传输数据时是采用明文传送，不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

HTTPS则是在HTTP的基础上加入了SSL/TLS协议，SSL/TLS依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

  • SSL和TLS都是加密协议（表示层协议），确保数据传输的安全，SSL是TLS的前身，现在都用TLS协议

  • TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

    （目前应用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都已经被认为是不安全的了）

    • Secure Socket Layer，安全套接字层
    • Transport Layer Security，传输层安全协议

HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性

二者区别

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

HTTPS与HTTP的一些区别

  • HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
  • HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
  • HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
  • HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

HTTP与HTTPS的区别,非常详细，推荐！！！
数字签名与数字证书与https关系
Wireshark抓包去分析https

7. HTTP1.0和1.1和2.0的区别

1.0与1.1的区别（长连接，缓存，部分，状态码，）

主要区别主要体现在：

  1. 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
  2. 带宽优化及网络连接的使用（支持断电传输，以及网页对象的部分传输），HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
  3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
  4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
  5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

HTTP2.0和HTTP1.X相比的新特性（二进制格式，多路复用，头部信息压缩）

  • 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
  • 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。
  • header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
  • 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

HTTP1.0、HTTP1.1 和 HTTP2.0 的区别,仔细看

http相关的问题汇总(牛客网)

8. HTTPS密钥交换过程（结合使用对称加密与非对称加密）

　（1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接。

　（2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。

　（3）客户端的浏览器与Web服务器开始协商SSL/TLS连接的安全等级，也就是信息加密的等级。

　（4）客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。

　（5）Web服务器利用自己的私钥解密出会话密钥。

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

证书颁发机构（CA, Certificate Authority）

[daɪˈdʒest , ˈdaɪdʒest] 摘要

https的密匙交换总结

step1: 客户端请求建立加密连接,服务器收到请求发送非对称加密所需要的私钥(包含在网络证书中)。

step2:客户端与浏览器协商安全等级，客户端建立会话秘钥(对称加密的钥匙)。

step3: 使用对称加密钥匙加密传输的信息，然后再使用非对称的公匙加密会话秘钥(对称加密的钥匙)，并传送给网站。

step4: 服务器用非对称加密的私钥获得会话秘钥(对称加密的钥匙)，然后再用会话密匙解密信息。

https为什么要结合对称加密与非对称加密？（从2种加密方式的优缺点考虑）

（1） 对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。
（2） 非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。
（3） 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

上文步骤的原文链接

https 结合使用 对称加密和非对称加密

9. HTTP的缓存机制

缓存分为服务端侧（server side，比如 Nginx、Apache）和客户端侧（client side，比如 web browser）。

服务端缓存

  • 代理服务器缓存(CDN 也是一种服务端缓存，目的都是让用户的请求走”捷径“，并且都是缓存图片、文件等静态资源,实际项目中一些前端框架的包比如vue,jquery可以通过CDN获取)
  • 反向代理服务器缓存（也叫网关缓存，比如 Nginx反向代理、Squid等）

客户端缓存

浏览器缓存控制机制有两种：HTML Meta标签 vs. HTTP头信息

Meta标签：在HTML页面中插入下面语句

<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
  • 上述代码的作用是告诉浏览器当前页面不被缓存，每次访问都需要去服务器拉取。使用上很简单
  • 只有部分浏览器可以支持，而且所有缓存代理服务器都不支持，因为代理不解析HTML内容本身。

HTTP头信息：

HTTP缓存有多种规则，根据是否需要重新向服务器发起请求来分类，我将其分为两大类(强制缓存，对比缓存)

  • 规则1：强制缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
    • 对于强制缓存来说，报文头部中会有两个字段来标明失效规则（Expires/Cache-Control）
      • Expires(1.0版本，已舍弃)
      • Cache-Control字段(缓存控制)：常见的取值有private( 客户端可以缓存)、public(客户端和代理服务器都可缓存)、no-cache(需要使用对比缓存来验证缓存数据)、max-age( 缓存的内容将在 xxx 秒后失效)，no-store(强制缓存，对比缓存都不会触发)，默认为private

  • 规则2：对比缓存，将缓存信息中的标识和资源最后修改时间通过请求发送给服务器，由服务器校验，返回304状态码时（即资源没有修改），浏览器直接使用缓存。
    • step1:客户端第一次请求的时候，服务端的应答报文中会包含Etag和Last-Modified字段
      • Etag：请求资源的唯一标识
      • Last-Modified: 浏览器资源的最后修改的时间
    • step2:再次请求服务器时，客户机通过If-Modified-Since 字段通知服务器上次请求时，服务器返回的资源最后修改时
      • 最后修改时间大于If-Modified-Since，则传输资源的最新内容，返回状态码200
      • 改时间小于或等于If-Modified-Since，说明资源无新修改，则响应HTTP 304，使用缓存。

浏览器 HTTP 协议缓存机制详解!!!!!!!

http缓存机制

彻底弄懂HTTP缓存机制及原理 推荐

10. 输入URL跳转网页的过程

从用户输入一个网址到网页最终展现到用户面前，中间的大致流程总结如下：

  1. 在客户端浏览器中输入网址URL。

  2. 通过应用层DNS协议获得域名对应的WEB服务器的IP地址

  3. 客户端浏览器与WEB服务器建立TCP(传输控制协议)连接。

  4. 客户端浏览器向对应IP地址的WEB服务器发送相应的HTTP或HTTPS请求。

  5. WEB服务器响应请求，返回指定的URL数据或错误信息****；如果设定重定向，则重定向到新的URL地址**。

  6. 客户端浏览器下载数据，解析HTML源文件，解析的过程中实现对页面的排版，解析完成后，在浏览器中显示基础的页面。

  7. 分析页面中的超链接，显示在当前页面，重复以上过程直至没有超链接需要发送，完成页面的全部显示。

11. 计算机网络四层协议,五层协议,七层协议

四层：应用层，传输层，网路层，网络接口层

五层：应用层，传输层，网络层，数据链路层，物理层

七层：应用层，表示层，会话层，传输层，网络层，数据链路层，物理层

12. 什么是cookie和session,区别是什么, 禁用cookie怎么办？

联系：

  • 这两种机制都是可以弥补HTTP协议无状态的不足

    • cookie可以看作是http协议的扩展，http报文头部有Set-Cookie(建立cookie)和Cookie字段

  • 大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器。

区别：

  • 数据存放地点：cookie数据存放在客户的浏览器上，服务器为每个用户创建session对象并将session数据放在服务器上；在服务端保存Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存服务比如Memcached之类的来放 Session。
由于session的追踪需要将session的id放入到cookie，如果禁用Cookie该怎么办？

一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。

2个机制总结：
  • Cookie是保存在浏览器上的一些数据，一般通过HTTP响应头set cookie来设置，当然也可以通过JS脚本来直接设置通常，它用于判断两个请求是否来自同一个浏览器 - 例如，保持用户登录。它记住无状态 HTTP协议的有状态信息。

cookie信息与session信息的区别，不仅仅是存储位置

深入理解Cookie与session机制
参考链接

13. 页面加载不出来的原因？

1、可能是页面的代码报错；

2、可能是后台的sql有问题。当查询的数据量过大时，而当前的sql不够优化，查询起来很费时，甚至出现无法获取最终结果的可能。

14 TCP快连接是什么，有什么用？

  • 上图中左边是TCP正常的3次挥手过程，每次连接都是正常的三次挥手。
  • 上图中的右边第一次连接是三次挥手，第二次连接就是快连接。

Fast open的设计目标：原本三次挥手的时候，前二次挥手需要进行同步是无法进行数据传输的。Fast Open实现建立的连接的时候就能够传送数据。

这种机制实现的核心在于： 客户端中存储了该服务器的Fast Open Cookie。

Fast Open过程：
  1. 客户端发送SYN数据包，该数据包包含数据（对于非TFO的普通TCP握手过程，SYN数据包中不包含数据）以及此前记录的Fast Open Cookie；
  2. 支持TCP Fast Open的服务器会对收到Cookie进行校验：
    • 如果Cookie有效，服务器将在SYN-ACK数据包中对SYN和数据进行确认（Acknowledgement），服务器随后将数据递送至相应的应用程序；
    • 否则，服务器将丢弃SYN数据包中包含的数据，且其随后发出的SYN-ACK数据包将仅确认（Acknowledgement）SYN的对应序列号；
  3. 如果服务器接受数据，客户端将发送ACK确认服务器发回的SYN以及数据，如果客户端在初始的SYN数据包中发送的数据未被确认，则客户端将重新发送数据；
  4. 此后的TCP连接和非TFO的正常情况一致。

注：客户端在请求并存储了Fast Open Cookie之后，可以不断重复TCP Fast Open直至服务器认为Cookie无效（通常为过期）。[4]

参考链接(推荐)

快连接注意点：

  • 需要系统与服务器的共同支持
  • 客户端在请求并存储了Fast Open Cookie之后，可以不断重复TCP Fast Open直至服务器认为Cookie无效

15 实现session共享的方案？

核心问题：多台服务器如何处理用户的session信息。

  • 方法1：每个服务器维护部分session信息，通过url 的映射实现（不进行共享）
  • 方法2：将用户的所有session信息集中存储（比如redis,mysql），集中获取。
  • 方法3：利用token，token的安全性该如何考虑。

注意点：这个问题考察了在分布式的场景下，服务端存储的session信息如何共享？

方法4： 服务器间同步比如tomcat集群：通过配置tomcat，实现session共享。每个tomcat都会在局域网中广播自己的session信息，同时监听其他tomcat广播的session，一旦自己的session发生变化，其他的tomcat能够感知到的，同时就可以同步自己的session和它一样。缺点：当集群服务器数量比较大如200台，每一台服务器的tomcat都需要广播自己的session，同时监听另外199台，此时，服务器的大量资源都用来处理session同步的事情，用户正常的访问就会受到影响。要视部署的tomcat集群数量等来定是否使用这种方式。

参考链接

16 传输层滑动窗口的实现？

  • 发送窗口根据确认号进行窗口的滑动
  • 接受窗口只接受在窗口内部的信息，接受信息后滑动接受窗口并设置确认号发送。

17 长连接与短连接 长连接如何实现 怎么将连接设置为短连接？

长连接：HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），继续用这个通道传输数据。

  • 长连接会用于一些点对点的频繁操作，并且不能太多
  • 结合TCP的保活机制，以及上层的应用通过心跳包来确定
Connection:keep-alive

短连接：在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。

  • 优点：短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费较多时间和带宽。

18 TCP何时会发送RST包？

FIN与RST都是用于关闭TCP连接的。

  • RST不必等缓冲区的包都发出去，直接就丢弃缓存区的包发送RST包。而FIN需要先处理完缓存区的包
  • 接收端收到RST包后，也不必发送ACK包来确认。而FIN需要ACK包确认

RST包接受方：收到RST信息，不会作任何响应，在RST位有效的情况下直接关闭连接。

发送RST包的集中情况

情况1：通信过程中有一方的连接被异常释放，会主动发送RST包给对方。

情况2：检测并关闭半打开连接，发送方通过已经废弃的连接发送数据(发送方认为这条连接有效，接受方认为这条连接无效)，接受方收到后会发送RST包。

情况3：发送方请求的端口号，服务方没有监听，服务方发送RST。

实际代码中哪些情况会检查RST标志位？

所有阶段都会检查

TCP合法RST报文

19 TCP的状态转移（重要）

上半部分建连过程，左下部分主动关闭连接过程和右下部分被动关闭连接过。

TIME_WAIT 状态：TCP 四次握手结束后，连接双方都不再交换消息，但主动关闭的一方保持这个连接在一段时间内不可用。

20 文件传输如何保证完整性？

常用的文件完整性校验算法

21 token和session区别？

token的应用场景：适用于项目级的前后端分离（前后端代码运行在不同的服务器下）

  • 请求登录: token和sessionId原理相同，对key和key对应的用户信息进行加密后的加密字符
  • 登录成功: 后端会将token传给客户端，客户端通过cookie、sessionStorage、localStorage都可存储token信息，
    • 注意点：再次请求不会默认携带token信息，需在请求拦截器中给请求头中添加认证字段Authorization携带token信息，服务器端就可以通过token信息查找用户登录状态。

参考链接

22 TCP三次握手补充

synchronized ['sɪŋkrənaɪzd]

三次握手的状态转移（结合19图）：

  • 服务端： 监听状态(Listen/passive open) => 接受到同步位状态(SYN_RECV/半连接状态) => ESTABLISHED
服务端状态转移总结：
1）初始状态服务端监听通信端口
2）当收到客户端带有同步标志位（SYN）的请求建立连接的包后，发送SYN与ACK给的包给客户端，进入到SYN_RECV状态也叫半连接状态。
3）最后收到客户端的确认包，进入established状态。
  • 客户端：发送同步标志位状态（SYN_SEND） => 连接建立状态
客户端状态转移总结：
1）初始状态服务端监听通信端口
2）当收到客户端带有同步标志位（SYN）的请求建立连接的包后，发送SYN与ACK给的包给客户端，进入到SYN_RECV状态也叫半连接状态。
3）最后收到客户端的确认包，进入established状态。

23 四次挥手中的close wait与time wait区分

close_wait状态定义:客户端主动关闭连接，服务器接收到客户端的FIN，但是还没有发送自己的FIN（响应太慢），此时的状态为close_wait状态，大量的close_wait状态拖累服务器性能

Time_wait状态定义：客户端接受到服务端的FIN,等待2MLS的时间。

closs wait的参考链接

参考资料

  • 王道计算机网络
posted @ 2021-05-17 22:41  狗星  阅读(462)  评论(0)  编辑  收藏  举报
/* 返回顶部代码 */ TOP