计算机网络汇总

五月 19, 2021 19408

一、网络分层模型

1、总体概述

OSI的七层模型和TCP/IP的四层模型：

OSI的七层模型和TCP/IP的四层模型

2、各层概述

物理层

物理层主要解决用何种信号传输比特0和1的问题。

物理层考虑的是怎样才能在连接各种计算机的传输媒体上传输数据比特流。物理层为数据链路层屏蔽了各种传输媒体的差异，使数据链路层只需要考虑如何完成本层的协议和服务，而不必考虑网络具体的传输媒体是什么。

物理层协议的主要任务：机械特性、电气特性、功能特性、过程特性。

传输数据格式：比特流

主要协议：RJ45、CLOCK

涉及设备：中继器；集线器；网关

涉及技术：编码与调制、信道复用

数据链路层

数据链路层主要解决分组在一个网络（或一段链路）上传输的问题。

涉及MAC地址及网卡地址。当一台设备连接到路由器，路由器连接到光猫上，而光猫则连通电信网络。当你从这台设备发出信息时，首先数据到达路由器，在通过路由器数据到达光猫，然后到达电信公网。在数据从设备到达路由器这一过程中是通过识别MAC地址完成的。也就是从一个节点到达另一个节点。而IP则是直接标识源和目的地。(即你的设备地址，和你所发送的设备地址)。

传输数据格式：帧（framing），在上层交付的数据单元添加帧头和帧尾，构成数据帧。

主要协议：PPP、FR、HDLC、VLAN、MAC 、CSMA/CD（载波监听多址接入/碰撞检测）

涉及设备：网桥；交换机

集线器（HUB）和交换机（SWITCH）的区别：

1.集线器是早期的以太网互联设备，已被淘汰，现使用交换机替代。

2.集线器工作在物理层；交换机工作在数据链路层和物理层

3.集线器对收到的信号进行放大、转发；交换机根据MAC地址，对帧进行转发

4.使用集线器作为互连设备的以太网仍然属于共享总线式以太网。集线器互连起来的所有主机共享总线带宽，属于同一个碰撞域和广播域；使用交换机作为互连设备的以太网，称为交换式以太网。交换机可以根据MAC地址过滤帧，即隔离碰撞域。

5.交换机的每个接口是一个独立的碰撞域；交换机隔离碰撞域但不隔离广播域(VLAN除外)

涉及技术：封装成帧、差错控制、可靠传输；媒体接入控制；虚拟局域网VLAN（使用交换机划分VLAN）

  • 封装成帧：数据链路层给上层交付的协议数据单元添加帧头和帧尾使之成为帧。数据链路层对上层交付的传输数据没有任何限制，好像数据链路层不存在一样，这称为透明传输。
  • 差错控制：奇偶校验、循环冗余校验（CRC）
  • 可靠传输：使用停止-等待协议SW、回退N帧协议GBN、选择重传协议SR三种可靠协议实现可靠传输

网络层

网络层主要解决在多个网络上传输（路由）的问题。

网络层的主要任务是实现网络互连，进而实现数据包在各网络之间的传输，这一层开始实现设备到设备之间的通信。

网络层提供的是无连接、不可靠的数据报服务，可靠通信应当由用户主机来保证。

传输数据格式：IP数据报

主要协议：IP、ICMP、ARP（根据IP地址获取MAC地址）、RARP、路由选择协议（RIP、OSPF、BGP）

路由器和交换机的区别：路由器可以隔离广播域和冲突域，交换机只能隔离冲突域。

涉及设备：路由器（ROUTER），路由器涉及到网络层及以下的各层。

涉及技术：IP地址，路由选择，虚拟专用网VPN，网络地址转换NAT

运输层

运输层主要解决进程之间基于网络的通信问题。

（1）运输层为应用程序提供端口供应用层使用，运输层的协议又称为端到端协议。

（2）当传输较大的文件时会将文件分段，那么为了保证这些数据正常的顺序，还要对数据进行重组，包括流量控制、差错控制，这些都由传输层完成控制。

传输数据格式：UDP用户数据报/TCP报文段

主要协议：TCP、UDP、SPX

涉及技术：端口号，TCP的流量控制、拥塞控制、连接的建立和释放（三次握手和四次挥手）

会话层

会话层解决进程之间进行会话问题

会将不同的应用程序的数据隔离起来。比如QQ与微信的隔离，使两个应用程序之间的数据进行隔离，防止串流。当然，如果想要共享两个软件之间的数据，可以通过应用层对应的接口进行共享。

主要协议：NFS、SQL、NETBIOS、RPC

表示层

表示层解决通信双方交互信息的表示问题

对应用数据转换。比如在QQ聊天时，音频通过对应软件的接口，传递给声卡，声卡把这些数据进行一个编码，变成比特数据传送到另一个人的设备上，然后在这台设备进行解码转化成语音。

主要协议：JPEG、MPEG、ASII

应用层

应用层解决通过应用进程之间的交互来实现特定网络应用的问题

最接近用户的一层。提供接口，使应用程序能够使用一些网络协议。

传输数据格式：数据包/HTTP请求报文

主要协议：HTTP、FTP、DNS、DHCP、Telnet、SMTP、POP3、 WWW、NFS

设计技术：域名、HTTP、文件传送协议FTP、电子邮件、万维网WWW

二、知识点详解

1、网络层

ICMP协议

ICMP（Internet Control Message Protocol），网际控制报文协议。为了更有效地转发IP数据报和提高交付成功的机会，在网际层使用ICMP协议。

主机或路由器使用ICMP来发送差错报告报文和询问报文。ICMP报文被封装在IP数据报中发送。

ICMP是IPv4协议族中的一个子协议，用于IP主机、路由器之间传递控制消息。

ICMP差错报告报文有以下五种：

  • 终点不可达：当路由器或主机不能交付数据报时，就向源点发送终点不可达报文。具体可再根据ICMP的代码字段细分为目的网络不可达、目的主机不可达、目的协议不可达、目的端口不可达、目的网络未知、目的主机为止等13种错误。
  • 源点抑制：当路由器或主机由于拥塞而丢弃数据报时，就向源点发送源点抑制报文，使源点知道应当把数据报的发送速率放慢。
  • 时间超过：当路由器收到一个目的IP地址不是自己的IP数据报，会将其生存时间TTL字段的值减1，若结果不为0，则将该IP数据报转发出去；若结果为0，除丢弃该IP数据报外，还要向源点发送时间超过报文。另外，当终点在预先规定时间内不能收到一个数据报的全部数据报片时，就把已收到的数据报片都丢弃，也会向源点发送时间超过报文。
  • 参数问题：当路由器或目的主机收到IP数据报后，根据其首部中的检验和字段发现首部在传输过程中出现了误码，就丢弃该数据报，并向源点发送参数问题报文。
  • 改变路由（重定向）：路由器把改变路由报文发送给主机，让主机知道下次应将数据报发送给另外的路由器（可通过更好的路由）。

ICMP询问报文有两种：

  • 回送请求和回答：ICMP回送请求报文是由主机或路由器向一个特定的目的主机发出的询问。收到此报文的主机必须给源主机或路由器发送ICMP回送回答报文。这种询问报文用来测试目的站是否可达及了解其有关状态。
  • 时间戳请求和回答：ICMP时间戳请求报文是请某个主机或路由器回答当前的日期和时间。在ICMP时间戳回答报文中有一个32位的字段，其中写入的整数代表从1900年1月1日起到当前时刻一共有多少秒。这种询问报文用来进行时钟同步和测量时间。

ICMP报文信息：

ICMP报文包含在IP数据报中，IP报头在ICMP报文的最前面。一个ICMP报文包括IP报头（至少20字节）、ICMP报头（至少8字节）和ICMP报文（属于ICMP报文的数据部分）。当IP报头中的协议字段值为1时，就说明这是一个ICMP报文。ICMP报头如下图所示。

ICMP报头格式

各字段说明

  • 类型：占一字节，标识ICMP报文的类型，目前已定义了14种，从类型值来看ICMP报文可以分为两大类。第一类是取值为1~127的差错报文，第2类是取值128以上的信息报文。
  • 代码：占一字节，标识对应ICMP报文的代码。它与类型字段一起共同标识了ICMP报文的详细类型。
  • 校验和：这是对包括ICMP报文数据部分在内的整个ICMP数据报的校验和，以检验报文在传输过程中是否出现了差错。其计算方法与在我们介绍IP报头中的校验和计算方法是一样的。
  • 标识：占两字节，用于标识本ICMP进程，但仅适用于回显请求和应答ICMP报文，对于目标不可达ICMP报文和超时ICMP报文等，该字段的值为0。

2、传输层

TCP和UDP对应的应用层协议和端口号如下：

TCP/IP体系的应用层常用协议所使用的运输层熟知端口号

TCP

TCP（控制传输协议），是一种面向连接的、可靠的、基于字节流的传输层通信协议。是为了在不可靠的互联网络上提供可靠的端到端字节流而专门设计的一个传输协议。

TCP报头信息

TCP报头信息

TCP报文是TCP层传输的数据单元，也叫报文段。TCP在发送数据时，从发送缓存中取出一部分或全部字节并给其添加一个首部使之成为TCP报文段后进行发送：

  • TCP报文段由首部和数据载荷两部分构成。
  • TCP的全部功能都体现在它首部中各字段的作用。

TCP报文段的首部内容：

  • 端口号：用来标识同一台计算机的不同的应用进程。

    • 源端口：占16比特，源端口用来标识发送该TCP报文段的应用进程，即报文的返回地址。
    • 目的端口：占16比特，目的端口指明接收方计算机上的应用程序接口。

    TCP报头中的源端口号和目的端口号，与IP数据报中的源IP和目的IP唯一确定一条TCP连接。

  • 序号和确认号：占32比特，是TCP可靠传输的关键部分。序号是本报文段发送的数据组的第一个字节的序号。在TCP传送的流中，每一个字节一个序号。比如一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为400。所以序号确保了TCP传输的有序性。确认号占32bit，即ACK，指明期待收到的下一个字节序号的值，同时也是对之前收到的所有数据的确认。比如N表明序号N之前的所有数据已经正确无误的收到。确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。

    TCP规定，连接建立后，所有传送的TCP报文段都必须把ACK置为1

  • 数据偏移／首部长度：占4比特，并以4字节为单位。用来指出数据载荷部分的起始处距离TCP报文段的起始处有多远。首部长度也叫数据偏移，是因为首部长度实际上指示了数据区在报文段中的起始偏移值（最小为0101，最大为1111）。由于首部可能含有可选项内容，因此TCP报头的长度是不确定的，报头不包含任何任选字段则长度为20字节，4位首部长度字段所能表示的最大值为1111，转化为10进制为15，15*4B= 60B，故报头最大长度为60字节。

  • 保留：占6比特，为将来定义新的用途保留，现在一般置0。

  • 控制位：URG ACK PSH RST SYN FIN，共6个，每一个标志位表示一个控制功能。

    • URG：紧急指针标志，为1时表示紧急指针有效，为0则忽略紧急指针。
    • ACK：确认序号标志，为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段。
    • PSH：push标志位，为1表示是带有push标志的数据，指示接收方在接收到该报文段以后，应尽快将这个报文段交给应用程序，而不是在缓冲区排队。
    • RST：重置连接标志，置为1时，用于重置由于主机崩溃或其他原因而出现错误的连接，或者用于拒绝非法的报文段和拒绝连接请求。
    • SYN：同步序号，用于建立连接过程，在连接请求中，SYN=1和ACK=0表示该数据段没有使用捎带的确认域，而连接应答捎带一个确认，即SYN=1和ACK=1。
    • FIN：finish标志，用于释放连接，为1时表示发送方已经没有数据发送了，即关闭本方数据流。

  • 窗口：占16比特，滑动窗口大小，指发送端的接受窗口大小，窗口值作为接收方让发送方设置其发送窗口的依据，以此控制发送端发送数据的速率，从而达到流量控制。窗口最大为65535。

  • 校验和：占16比特，奇偶校验，此校验和是对整个的 TCP 报文段，包括 TCP 头部和 TCP 数据。由发送端计算和存储，并由接收端进行验证。

  • 紧急指针：占16比特，只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量，表明本报文字段数据载荷部分包含了多长的紧急数据。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。

  • 选项和填充：选项长度不一定是32位的整数倍，所以要加填充位，即在这个字段中加入额外的零，以保证TCP头是32的整数倍。常见的选项有：

    • 最长报文段长度，又称为MSS（Maximum Segment Size），每个连接方通常都在通信的第一个报文段（为建立连接而设置SYN标志为1的那个段）中指明这个选项，它表示本端所能接受的最大报文段的长度。
    • 窗口扩大选项：为了扩大窗口，提高吞吐率
    • 时间戳选项：用于计算往返时间RTT；用于处理序号超出范围的情况，又称为防止序号绕回PAWS
    • 选择确认选项：用于实现选择确认功能。

  • 数据部分： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

TCP元组

这些元组主要是用于端口复用的，对于一个连接来说，只要其中一个存在不同则可以区别这是一个不同的连接。

四元组：

1
源IP地址、目的IP地址、源端口、目的端口

五元组:

1
源IP地址、目的IP地址、协议号、源端口、目的端口

七元组:

1
源IP地址、目的IP地址、协议号、源端口、目的端口，服务类型以及接口索引

三次握手

主动发起连接建立的应用进程叫做TCP客户端。

被动等待连接建立的应用进程叫做TCP服务端。

（1）第一次握手：客户端给服务端发一个 SYN 报文，这是一个并指明客户端的初始化序列号 ISN。客户端进入 SYN_SENT 状态。发送内容：SYN=1，seq=x。

SYN=1，表明这是一个TCP连接请求报文段。

TCP规定，SYN=1的报文段不能携带数据，但要消耗掉一个序号。

（2）第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值（即x+1），表示自己已经收到了客户端的 SYN，服务器进入 SYN_RCVD 的状态。确认报文段内容为：SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。

（3）第三次握手：客户端收到 SYN 报文之后，会发送一个普通的确认报文段。。同样把服务器的 ISN + 1 作为 ACK 的值（即y+1），表示已经收到了服务端的 SYN 报文，客户端进入ESTABLISHED 状态。服务器收到 ACK 报文之后，也进入ESTABLISHED 状态，此时，双方已建立起了连接。确认报文段内容：ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1）。

普通的ACK报文段可以携带数据，不携带数据则不消耗序号。

发送第一个SYN的一端为主动打开（active open），接收这个SYN并发回下一个SYN的另一端为被动打开（passive open）。

在socket编程中，客户端执行connect()时，将触发三次握手。

第三次握手的情况下，ACK数据包如果丢失，有两种情况:

1、客户端接着发送数据包，服务器端收到数据包，这个时候数据包带有和ACK一样的信息，因此不需要进行重传。

2、如果客户端没有发送数据包，那么过了2ms，服务器端会认为自己的ACK数据包丢失了，进行重传，这个时候客户端才重传对应的数据包。

三次握手过程

三次握手的目的

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。因此，需要三次握手才能确认双方的接收与发送能力是否正常。

采用三次握手而不是两次握手的原因：为了防止已经失效的连接请求报文段突然又传到了TCP服务器，因而导致错误。

具体来说，客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，如果只采用两次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一直等待客户端发送数据，浪费资源。

初始序列号，ISN(Initial Sequence Number)：

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。三次握手的其中一个重要功能是客户端和服务端交换 ISN，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

泛洪攻击：

​ SYN泛洪攻击属于Dos攻击的一种，该攻击是借助于TCP的三次握手实现的。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

解决措施：

​ 对于SYN泛洪攻击的防范，优化主机系统设置是常用的手段。如降低SYN timeout时间，使得主机尽快释放半连接的占用；又比如采用SYN cookie设置，如果短时间内连续收到某个IP的重复SYN请求，则认为受到了该IP的攻击，丢弃来自该IP的后续请求报文。此外合理地采用防火墙等外部网络安全设施也可缓解SYN泛洪攻击。

四次挥手

客户端和服务端都可以在数据传送结束后发出连接释放的通知，即主动关闭。

以客户端主动发起连接释放申请为例：

（1）第一次挥手：客户端想断开连接时，主动发送一个 FIN 报文（即连接释放报文段），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。连接释放报文段内容为：FIN=1，ACK=1，seq=u，ack=v，

FIN=1，ACK=1，表明这是一个TCP连接释放报文段，同时也对之前收到的报文段进行确认。

TCP规定，终止位FIN等于1的报文段即使不携带数据，也要消耗掉一个序号。连接释放报文段可以携带数据也可以不携带数据。

（2）第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文。服务端发出确认报文段后进入CLOSE_WAIT（关闭等待）状态，此时从TCP客户端到服务端的连接就关闭了，TCP处于半关闭状态（服务端到客户端的连接没有关闭，服务端仍可以向客户端发送数据）。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。确认报文段内容ACK=1，seq=v，ack=u+1

（3）第三次挥手：如果服务端没有数据发送，也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。服务端处进入LAST_ACK （最后确认）状态，等待客户端的确认。连接释放报文段内容为：FIN=1，ACK=1，seq=w，ack=u+1，u+1是对之前收到的TCP连接释放报文段的重复确认。

第三次挥手是多出的一次挥手，主要原因在于可能双方连接断开的时候，服务端到客户端的数据传输还没有完成，因此需要多一次等待数据传输完成。一旦服务端没有数据发送了，就可以发送FIN报文。

（4）第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，客户端进入 TIME_WAIT 状态。客户端需要等待2MSL时间，确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，而服务端收到 ACK 报文之后，就关闭连接，进入 CLOSED 状态。确认报文段内容为：ACK=1，seq=u+1，ack=w+1

四次挥手过程

TIME_WAIT状态：服务端发送最后一次释放连接请求后（即第三次挥手），可能由于网络比较阻塞，该数据帧在传送过程中丢失了。服务器可能会再次进行确认，但是此时如果客户端已经进入CLOSE状态，不会理会其他的请求。因此，采用TIME_WAIT来保障如果网络比较阻塞，可以保证最后一次的ACK报文段能够到达服务端，正常关闭TCP连接。TIME_WAIT是主动断开链接发起者的状态，在发送最后一次ACK后进入TIME_WAIT状态。经过2MSL时长，可以使本次连接持续时间内所产生的所有报文段都从网络中消失，可以使下一次新的TCP连接中，不会出现旧连接中的报文段。

CLOSE_WAIT状态：在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。在这个状态下，出于被动关闭的服务端可以继续将未发送完的数据发送给客户端。

MSL（Maximum Segment Lifetime）：最长报文寿命，RFC793建议为2分钟。TCP允许不同的实现可以根据具体情况使用更小的MSL的值。

保活计时器：为了保证TCP客户端出现故障时，服务端不再白白等待下去，TCP服务器使用保活计时器。TCP服务器进程每收到一次TCP客户进程的数据，就重新设置并启动保活计时器（2小时定时）。若保活计时器定时周期内未收到TCP客户进程发来的数据，则当保活计时器到时后，TCP服务器进程就向TCP客户进程发送一个探测报文段，以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无TCP客户进程的响应，TCP服务器进程就认为TCP客户进程所在主机出了故障，接着就关闭这个连接。

流量控制

所谓流量控制(flow control)，就是让发送方的速率不要太快，要让接收方来得及接收。

TCP的流量控制通常采用滑动窗口实现。(滑动窗口的大小取决于接收方的窗口大小和信道大小)：

  • TCP接收方利用自己的接收窗口的大小来限制发送方发送窗口的大小。
  • TCP发送方收到接收方的零窗口通知后，应启动持续计时器。持续计时器超时后，向接收方发送零窗口探测报文。

滑动窗口有以下几种方法：

（1）停止等待协议，当发送窗口和接收窗口都等于1时，就是停止等待协议。发送端给接收端发送数据，等待接收端确认回复ACk，并停止发送新的数据包，开启计时器。数据包在计时器超时之前得到确认，那么计时器就会关闭，并发送下一个数据包。如果计时器超时，发送端就认为数据包丢失或被破坏，需要重新发送之前的数据包，说明数据包在得到确认之前，发送端需要存储数据包的副本。停止等待协议是发出一个帧后得到确认才发下一个，降低了信道的利用率。

（2）后退N帧协议，在发送完一个帧后，不用停下来等待确认，而是可以连续发送多个数据帧。收到确认帧时，任可发送数据，这样就减少了等待时间，整个通信的通吞吐量提高。如果前一个帧在超时时间内未得到确认，就认为丢失或被破坏，需要重发出错帧及其后面的所有数据帧。这样有可能有把正确的数据帧重传一遍，降低了传送效率。线路很差时，使用退后N帧的协议会浪费大量的带宽重传帧。

（3）选择重传协议，NAK：非确认帧，当在一定时间内没有收到某个数据帧的ACK时，回复一个NACK。在发送过程中，如果一个数据帧计时器超时，就认为该帧丢失或者被破坏，接收端只把出错的的帧丢弃，其后面的数据帧保存在缓存中，并向发送端回复NAK。发送端接收到NAK时，只发送出错的帧。如果落在窗口的帧从未接受过，那么存储起来，等比它序列号小的所有帧都按次序交给网络层，那么此帧才提交给网络层。接收端收到的数据包的顺序可能和发送的数据包顺序不一样。因此在数据包里必须含有顺序字符来帮助接受端来排序。选择重传协议可以避免重复传送那些正确到达接收端的数据帧。但是接收端要设置具有相当容量的缓存空间，这在许多情况下是不够经济的。

拥塞控制

拥塞，即对资源的需求超过了该资源所能提供的可用部分。若网络中许多资源同时供应不足，即出现拥塞，如果不进行控制，网络的性能就要明显变坏，整个网络的吞吐量随之负荷的增大而下降。

计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。

拥塞避免的方式主要包括慢开始，拥塞避免，快重传，快恢复。

前提

发送方维护一个叫做拥塞窗口cwnd的状态变量，其值取决于网络的拥塞程度，并且动态变化。

  • 拥塞窗口cwnd的维护原则：只要网络没有出现拥塞，拥塞窗口就再增大一些；但只要网络出现拥塞，拥塞窗口就减少一些。
  • 判断出现网络拥塞的依据：没有按时收到应当到达的确认报文（即发生超时重传)。

发送方将拥塞窗口作为发送窗口swnd，即swnd = cwnd。

发送方的窗口的上限值应当取为接收方窗口rwnd和拥塞窗口cwnd这两个变量中较小的一个.

维护一个慢开始门限ssthresh状态变量：

  • 当cwnd < ssthresh时，使用慢开始算法;
  • 当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法;
  • 当cwnd = ssthresh时，即可以使用慢开始算法，也可以使用拥塞避免算法。

1、慢开始（slow-start）：

​ 慢开始指的是一开始向网络中注入的报文段少。当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么就有可能引起网络拥塞，因为现在并不清楚网络的负荷情况。因此，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚开始发送报文段时，先把拥塞窗口 cwnd 设置为一个最大报文段MSS的数值。而在每收到一个对新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口 cwnd ，可以使分组注入到网络的速率更加合理。

2、拥塞避免（congestion avoidance）：

​ 让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认），就要把慢开始门限ssthresh设置为出现拥塞时的发送方窗口值的一半（但不能小于2）。然后把拥塞窗口cwnd重新设置为1，执行慢开始算法。这样做的目的就是要迅速减少主机发送到网络中的分组数，使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。

TCP Tahoe版本

3、快重传(fast retransmit)：

如果传输时出现了超时，发送方会误以为发生了拥塞，从而将cwnd重新置为1，这样会降低效率，因此1990年增加了快重传和快恢复两个改进的算法。

所谓快重传，就是使发送方尽快进行重传，而不是等超时重传计时器超时再重传：

  • 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认（ACK）。
  • 即使收到了失序的报文段，也要立即发出对已收到的报文段的重复确认。
  • 发送方一旦收到3个连续的重复确认，就将相应的报文段立即重传，而不是等该报文段的超时重传计时器超时再重传。

对于个别丢失的报文段，发送方不会出现超时重传，也就不会误以为出现了拥塞（进而降低拥塞窗口cwnd为1）。使用快重传可以使整个网络的吞吐量提高约20%。

收到3个重复确认后，知道是丢失了个别的报文段，于是不启动慢开始算法，而执行快恢复算法，具体做法为：

快重传

4、快恢复(fast recovery)：

使用快重传算法，收到3个重复确认时，会执行快恢复算法，具体做法为：

  • 把ssthresh设置为cwnd的一半；

  • 把cwnd再设置为ssthresh的值；

    有些快恢复实现将cwnd重置为ssthresh+3，理由是3个重复确认说明有3个数据报文段离开了网络，这3个报文段不在消耗网络资源，而是停留在接收方的接收缓存中。网络中不是堆积了报文段，而是减少了3个报文段，因此可以适当把拥塞窗口再扩大些。

  • 重新进入拥塞避免阶段。

慢开始和拥塞避免算法是1988年提出的TCP拥塞控制算法，称为TCP Tahoe版本。

1990年提出了快重传和快恢复算法，称为TCP Reno版本。

超时重传时间

超时重传计算公式

例如：

超时重传时间计算例题

可靠传输

通过以上TCP的内容，可以总结出TCP实现可靠传输，主要依靠以下机制：

  • 连接管理：三次握手和四次挥手机制。
  • 数据分块传输。数据被分为TCP认为合适的数据块进行传输。
  • 使用校验和校验：将发送的数据段都当作一个16位的整数，相加，进位不丢弃补在后面，最后取反得到校验和
  • 确认应答和序列号：TCP传输时对每个字节的数据都进行了编号，每次接收方收到数据后，都会对传输方进行确认应答(ACK)，其中带有对应的确认序列号，告诉发送方已经接收到了哪些数据，下一次希望接收的数据的序列号。
  • 流量控制：滑动窗口
  • 拥塞控制：慢开始、拥塞避免、快重传、快恢复
  • 超时重传机制。

粘包问题

粘包指的是由于连续的数据传送，导致多个数据包混合在一起，没有办法有效的区分开。TCP是基于字节流的，只维护发送出去多少，确认了多少，并没有维护消息与消息之间的边界，因而极有可能导致粘包问题：

  • 发送端，TCP为提高传输效率，发送方要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。
  • 接收方引起的粘包是由于接收方用户进程不及时接收数据，或者当发送内容较大时，由于服务器端的recv(buffer_size)方法中的buffer_size较小，不能一次性完全接收全部内容，因此在下一次请求到达时，接收缓冲区还有上一次的内容，取出的数据包括了上一次没有完全接收完的内容，从而造成粘包现象

UDP方案不会出现粘包，因为其有对应的数据分割。

解决方法：

  • 对于发送方引起的粘包现象，用户可通过编程设置来避免，TCP提供了强制数据立即传送的操作指令push，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满。

  • 对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象；发送端可以在发送数据之前向接收端告知发送内容的大小

UDP

Internet 协议集支持一个无连接的传输协议，该协议称为用户数据报协议（UDP，User Datagram Protocol）。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法。

UDP传输的可靠性由应用层负责。常用的UDP端口号有：53（DNS）、69（TFTP）、161（SNMP），使用UDP协议包括：TFTP、SNMP、DNS、DHCP、RIP（路由信息协议）

UDP报头由4个域组成，其中每个域各占用2个字节，具体包括源端口号、目标端口号、数据包长度、校验值。

TCP与UDP的区别

1、连接方面区别

TCP面向连接（如打电话要先拨号建立连接）。有三次握手建立连接，四次挥手释放连接。

UDP是无连接的，即发送数据之前不需要建立连接。

2、安全方面的区别

TCP提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。

UDP尽最大努力交付，即不保证可靠交付。

3、传输效率的区别

TCP传输效率相对较低。

UDP传输效率高，适用于对高速传输和实时性有较高的通信或广播通信。

4、连接对象数量的区别

TCP连接只能是点到点、一对一的，是全双工的。

UDP支持一对一，一对多，多对一和多对多的交互通信。

5、运输过程的区别

TCP面向字节流，这正是TCP实现可靠传输、流量控制、拥塞控制的基础。TCP将应用进程交付下来的数据块看作是无结构的字节流，更具发送策略，提取一定量的字节构建TCP报文并发送。

UDP面向报文，对应用进程交下来的报文即不合并也不拆分，而是保留这些报文的边界。

6、结构方面的区别

TCP首部最小20字节，最大60字节。因为其要提供可靠传输，因此首部字段包含固定部分20字节和可变部分最大40字节。

UDP首部开销小，仅8个字节。

7、应用场景

TCP的可靠性，决定了其适用于准确率要求高，效率要求低的场景，例如文件传输。

UDP的不可靠性，决定了其适用于效率要求高，准确率要求低的场景，例如IP电话、视频会议、直播等。

3、HTTP与HTTPS

HTTP特点

HTTP协议的五大特点：支持客户/服务器模式、简单快速、灵活、无连接、无状态。无连接指的是请求时建立连接，请求完释放连接。

无状态是指：

  • 协议对于事务处理没有记忆能力。

  • 对同一个url请求没有上下文关系。

  • 每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况。

  • 服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器。

Cookies/Session

这两个主要用于解决HTTP无状态连接的问题，服务器会给每个会话创建对应的SessionID，会根据SessionID判断当前登陆的用户。

Session是服务端用来记录用户状态的一种机制，或者说是存放在服务端用于跟踪用户状态的一个数据结构（对象）。服务端为每个特定的用户创建特定的Session，用于标识用户，记录用户的行为，这个Session有唯一的标识Session Id。Session Id一般存放在Cookie中，每次HTTP请求的时候，客户端会发送相应的Cookie信息到服务端，用于识别用户身份，然后从Session中查找用户状态。Cookie是Session的一种实现，Session实现会话管理机制时，利用了Cookie技术。Session默认存放在服务器的文件里，也可以存放在数据库、内存中。

Cookie是一小段的文本信息，用于客户端保存用户信息，将无状态的HTTP进行状态化。当用户客户端通过 HTTP 协议访问一个服务器的时候，如果服务器需要记录该用户的状态，就为该用户生成一个唯一的Cookie识别码，并以此为索引在服务器后端数据库中创建一个项目，用来记录该用户访问该网站的各种信息，并将HTTP响应内容和 Key/Value 键值对返回给客户端浏览器。客户端浏览器会把Cookier保存起来。当浏览器再次请求该网站时，浏览器就会把请求地址和Cookie 一同给服务器。服务器检查该Cookie ，从而判断用户的状态。服务器还可以根据需要修改Cookie 的内容。Cookie一般会存放Session Id和用户名等其他用户信息。

服务器将Cookie添加到response里一并返回给客户端，然后客户端会自动把response里的cookie接收下来，并且保存到本地，下次发出请求的时候，就会把cookie附加在request里，服务器在根据request里的cookie遍历搜索是否有与之符合的信息。

如果禁用Cookie，就无法获取Session Id，这时可以使用URL地址重写技术，将用户Session的id信息重写到URL地址中，这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。

使用Cookie在服务器上记录用户信息

Session和Cookie区别：

  • 存储位置：Cookie保存在客户端浏览器中的，而Session保存在服务器上。
  • 安全性：与Session相比，Cookie由于保存在客户端，安全性较低。
  • 存储容量：Session存储容量可以很大，Cookie存储容量很小。
  • 如果说cookie机制是检查客户身上的“通行证”，那么session机制就是通过检查服务器上的“客户明细表”来确认客户身份。

利用cookie和session登录的流程

客户输入账号密码进行首次登录，服务器端进行验证，验证成功则生成唯一的Session Id，并且在session对象中存储当前用户信息。服务器端将Session Id写入客户端Cookie中，当客户端下次访问服务器端时Cookie会被自动发送给服务器端，服务器端在Cookie中拿到Session Id然后在服务器端的Session对象中查找Session Id进行验证，验证成功说明用户是登陆状态，则可以为其响应只有在登陆状态才能响应的数据，还原用户上次的浏览状态或提供其他个性化服务。

HTTP状态码

1、消息(1XX)：

  • 100 Continue，客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。

2、成功(2XX):

  • 200 OK，请求已成功
  • 201 Created，请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。

3、重定向(3XX)：

  • 300 Multiple Choices，被请求的资源有一系列可供选择的回馈信息，每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
  • 301: 永久重定向，表示本网页永久性转移到另一个地址。
  • 302：重定向，当响应码为302时，表示服务器要求浏览器重新再发一个请求，服务器会发送一个响应头Location，它指定了新请求的URL地址；
  • 304: 服务器端会获取If-Modified-Since值，与index.html 的当前最后修改时间比对，如果相同，服务器会发响应码304，表示index.html与浏览器上次缓存的相 同，无需再次发送，浏览器可以显示自己的缓存页面，如果比对不同，那么说明index.html已经做了修 改，服务器会响应200。

4、请求错误（4XX）:

  • 400 Bad Request：
    • a.语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。
    • b.请求参数有误。
  • 403 Forbidden，服务器已经理解请求，但拒绝执行它。
  • 404 Not Found，请求失败，请求所希望得到的资源未被在服务器上发现。

5、服务器错误（5XX）:

  • 500 Internal Server Error，服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器端的源代码出现错误时出现。
  • 503 Service Unavailable，由于临时的服务器维护或者过载，服务器当前无法处理请求。
  • 504 Gateway Timeout，作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
  • 505 HTTP Version Not Supported，服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

HTTP方法

  • GET，GET 用于从指定资源请求数据。是幂等的，GET请求的参数数量是有限的，且参数暴露在URL中，安全性没有POST高

  • POST，POST 用于将数据发送到服务器来创建/更新资源，是不幂等的。

    post请求几种常见content-type类型：

    1. application/x-www-form-urlencoded：原生form表单
    2. multipart/form-data：许多文件类型，比如文件
    3. application/json：告诉服务端消息主体是JSON
    4. text/xml：传输和存储数据
    5. binary：二进制文件类型

  • PUT，PUT 用于将数据发送到服务器来创建/更新资源。POST 和 PUT之间的区别在于 PUT 请求是幂等的（idempotent）。也就是说，多次调用相同的 PUT 请求将始终产生相同的结果。相反，重复调用POST请求具有多次创建相同资源的副作用。

  • HEAD，HEAD 与 GET 几乎相同，但没有响应主体。换句话说，如果 GET /users 返回用户列表，那么 HEAD /users 将发出相同的请求，但不会返回用户列表。HEAD 请求对于在实际发出 GET 请求之前（例如在下载大文件或响应正文之前）检查 GET 请求将返回的内容很有用。
  • DELETE，删除指定的资源。
  • PATCH，对PUT方法的补充，用来对已知资源进行局部更新。
  • OPTIONS，请求一些选项信息。

长连接与短连接

当浏览器访问一个包含多张图片的 HTML 页面时，除了请求访问的 HTML 页面资源，还会请求图片资源。如果每进行一次 HTTP 通信就要新建一个 TCP 连接，那么开销会很大。

长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。

  • 从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；
  • 在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。

HTTP1.0、1.1、2.0的区别

HTTP1.X：线程阻塞，同一时间同一域名的请求有一定数量限制，超过限制数目的请求会被阻塞

HTTP1.0和HTTP1.1主要区别：HTTP1.0默认使用短连接，HTTP1.1默认使用长连接

HTTP2.0：

  • 采用二进制格式而非文本格式
  • 完全多路复用，而非有序并阻塞的、只需一个连接即可实现并行
  • 使用报头压缩，降低开销
  • 服务器推送

​

HTTPS

HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

SSL/TLS加密过程：

（1） 客户端向服务器端索要并验证公钥。

（2） 双方协商生成”对话密钥”。

（3） 双方采用”对话密钥”进行加密通信。

HTTPS

HTTPS的缺点：

  • 相同环境下HTTPS的响应时间和需要的资源相比HTTP都大幅上升
  • HTTPS的安全范围有限，在黑客攻击和服务器劫持等情况几乎起不到作用

HTTP/HTTPS的区别

  • HTTP 信息是明文传输，内容可能会被窃听，不安全，HTTPS 的数据是加密传输的（HTTP+SSL/TLS），且可进行身份认证，安全性较好。
  • HTTP响应速度比HTTPS快，因为HTTPS多了一层加密层。
  • HTTP端口号为80，而HTTPS端口号为443，二者使用完全不同的连接方式。
  • HTTPS 协议需要到CA申请证书，一般免费证书较少，因而需要一定费用。

4、加密

对称密钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。

  • 优点：运算速度快；
  • 缺点：无法安全地将密钥传输给通信方。

对称密钥加密

非对称密钥加密

非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。

公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。

  • 优点：可以更安全地将公开密钥传输给通信发送方；
  • 缺点：运算速度慢。

非对称密钥加密

HTTPS的加密方式

上面提到对称密钥加密方式的传输效率更高，但是无法安全地将密钥 Secret Key 传输给通信方。而非对称密钥加密方式可以保证传输的安全性，因此我们可以利用非对称密钥加密方式将 Secret Key 传输给通信方。HTTPS 采用混合的加密机制，正是利用了上面提到的方案：

  • 先使用非对称密钥加密方式传输对称密钥加密方式所需要的 Secret Key，从而保证安全性;
  • 获取到 Secret Key 后，再使用对称密钥加密方式进行通信，从而保证效率。

三、常见问题

1、输入URL后发生了什么？

1、应用层DNS解析域名。

​ 浏览器会根据输入的URL去查找对应的IP，寻找的过程遵循就近原则，依次是：浏览器缓存 -> 系统缓存 -> 路由器缓存->本地（ISP）域名服务器缓存 -> 根域名服务器。

2、TCP连接（三次握手）。

​ 浏览器得到IP以后，向服务器发送TCP连接请求，三次握手建立TCP连接。

3、浏览器发送HTTP请求。

​ 浏览器向web服务器发送一个HTTP请求。HTTP的请求方式为get，这个get请求包含了主机（Host）、用户代理(User-Agent)，用户代理就是自己的浏览器，它是你的”代理人”，Connection（连接属性）中的keep-alive表示浏览器告诉对方服务器在传输完现在请求的内容后不要断开连接，不断开的话下次继续连接速度就很快了。可能还会有Cookies，Cookies保存了用户的登陆信息，一般保存的是用户的SessionId，在每次向服务器发送请求的时候会重复发送给服务器，服务器就知道是哪个浏览器。

如果有重定向，则会执行服务器的永久重定向—>浏览器跟踪对应的重定向地址。

4、服务器处理并发回请求。服务器返回响应头（包含状态码）和具体的要请求的页面内容。

5、浏览器解析对应的HTML响应内容：

6、关闭TCP连接（四次挥手）。

查看评论