OSI七层模型

Xnip2022-03-24_15-07-34

OSI七层模型 功能 对应的网络协议 TCP/IP四层概念模型
应用层 文件传输，文件管理，电子邮件的信息处理 HTTP、TFTP, FTP, NFS, WAIS、SMTP 应用层
表示层 确保一个系统的应用层发送的消息可以被另一个系统的应用层读取，编码转换，数据解析，管理数据的解密和加密。 Telnet, Rlogin, SNMP, Gopher 应用层
会话层 负责在网络中的两节点建立，维持和终止通信。 SMTP, DNS 应用层
传输层 定义一些传输数据的协议和端口。 TCP, UDP 传输层
网络层 控制子网的运行，如逻辑编址，分组传输，路由选择 IP, ICMP, ARP, RARP, AKP, UUCP 网络层
数据链路层 主要是对物理层传输的比特流包装，检测保证数据传输的可靠性，将物理层接收的数据进行MAC（媒体访问控制）地址的封装和解封装 FDDI, Ethernet, Arpanet, PDN, SLIP, PPP，STP。HDLC,SDLC,帧中继 数据链路层
物理层 定义物理设备的标准，主要对物理连接方式，电气特性，机械特性等制定统一标准。 IEEE 802.1A, IEEE 802.2到IEEE 802.3 数据链路层

OSI七层模型及其包含的协议如下:

物理层

通过媒介传输比特,确定机械及电气规范,传输单位为bit，主要包括的协议为：IEE802.3 CLOCK RJ45

通道

单向通道（单工通道）：只有一个方向通信，没有反方向交互，如广播

双向交替通信（半双工通信）：通信双方都可发消息，但不能同时发送或接收

双向同时通信（全双工通信）：通信双方可以同时发送和接收信息

通道复用技术

频分复用（FDM，Frequency Division Multiplexing）：不同用户在不同频带，所用用户在同样时间占用不同带宽资源

时分复用（TDM，Time Division Multiplexing）：不同用户在同一时间段的不同时间片，所有用户在不同时间占用同样的频带宽度

波分复用（WDM，Wavelength Division Multiplexing）：光的频分复用

码分复用（CDM，Code Division Multiplexing）：不同用户使用不同的码，可以在同样时间使用同样频带通信

数据链路层

将比特组装成帧和点到点的传递,传输单位为帧,主要包括的协议为MAC VLAN P2P

点对点信道

  • 数据单元：帧

三个基本问题：

  • 封装成帧：把网络层的 IP 数据报封装成帧，SOH - 数据部分 - EOT

  • 透明传输：不管数据部分什么字符，都能传输出去；可以通过字节填充方法解决（冲突字符前加转义字符）

  • 差错检测：降低误码率（BER，Bit Error Rate），广泛使用循环冗余检测（CRC，Cyclic Redundancy Check）

点对点协议（Point-to-Point Protocol）：用户计算机和 ISP 通信时所使用的协议

广播信道

广播通信：

  • 硬件地址（物理地址、MAC 地址）

  • 单播（unicast）帧（一对一）：收到的帧的 MAC 地址与本站的硬件地址相同

  • 广播（broadcast）帧（一对全体）：发送给本局域网上所有站点的帧

  • 多播（multicast）帧（一对多）：发送给本局域网上一部分站点的帧

网络层

负责数据包从源到宿的传递和网际互连，传输单位为包,主要包括的协议为IP ARP

IP（Internet Protocol，网际协议）是为计算机网络相互连接进行通信而设计的协议。

ARP（Address Resolution Protocol，地址解析协议）:

根据IP地址获取物理地址的一个TCP/IP协议。使用地址解析协议，可根据网络层IP数据包包头中的IP地址信息解析出目标硬件地址（MAC地址）信息，以保证通信的顺利进行。

ICMP（Internet Control Message Protocol，网际控制报文协议）

IGMP（Internet Group Management Protocol，网际组管理协议）

IP 地址分类：

IP 地址 ::= {<网络号>,<主机号>}

IP 地址类别 网络号 网络范围 主机号 IP 地址范围
A 类 8bit，第一位固定为 0 0 —— 127 24bit 1.0.0.0 —— 127.255.255.255
B 类 16bit，前两位固定为 10 128.0 —— 191.255 16bit 128.0.0.0 —— 191.255.255.255
C 类 24bit，前三位固定为 110 192.0.0 —— 223.255.255 8bit 192.0.0.0 —— 223.255.255.255
D 类 前四位固定为 1110，后面为多播地址
E 类 前五位固定为 11110，后面保留为今后所用

IP 数据报格式：

image-20220326105551855

IP多播

IGMP（Internet Group Management Protocol，网际组管理协议）

多播路由选择协议

VPN 和 NAT

VPN（Virtual Private Network，虚拟专用网）

NAT（Network Address Translation，网络地址转换）

路由表包含什么？

网络 ID（Network ID, Network number）：就是目标地址的网络 ID。

子网掩码（subnet mask）：用来判断 IP 所属网络

下一跳地址/接口（Next hop / interface）：就是数据在发送到目标地址的旅途中下一站的地址。其中 interface 指向 next hop（即为下一个 route）。一个自治系统（AS, Autonomous system）中的 route 应该包含区域内所有的子网络，而默认网关（Network id: 0.0.0.0, Netmask: 0.0.0.0）指向自治系统的出口。

根据应用和执行的不同，路由表可能含有如下附加信息：

花费（Cost）：就是数据发送过程中通过路径所需要的花费。

路由的服务质量

路由中需要过滤的出/入连接列表

传输层

提供端到端的可靠报文传递和错误恢复，传输单位为报文,主要包括的协议为TCP UDP

TCP

  • TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，其传输单位是报文段。

特征：

面向连接

点对点通信

可靠交互

全双工通信

面向字节流

TCP 如何保证可靠传输：

确认和超时重传

数据合理分片和排序

流量控制

拥塞控制

数据校验

TCP：状态控制码（Code，Control Flag），占 6 比特，含义如下：

  • URG：紧急比特（urgent），当 URG＝1 时，表明紧急指针字段有效，代表该封包为紧急封包。它告诉系统此报文段中有紧急数据，应尽快传送(相当于高优先级的数据)， 且上图中的 Urgent Pointer 字段也会被启用。
  • ACK：确认比特（Acknowledge）。只有当 ACK＝1 时确认号字段才有效，代表这个封包为确认封包。当 ACK＝0 时，确认号无效。
  • PSH：（Push function）若为 1 时，代表要求对方立即传送缓冲区内的其他对应封包，而无需等缓冲满了才送。
  • RST：复位比特(Reset)，当 RST＝1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。
  • SYN：同步比特(Synchronous)，SYN 置为 1，就表示这是一个连接请求或连接接受报文，通常带有 SYN 标志的封包表示『主动』要连接到对方的意思。
  • FIN：终止比特(Final)，用来释放一个连接。当 FIN＝1 时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。

UDP

  • UDP（User Datagram Protocol，用户数据报协议）是 OSI（Open System Interconnection 开放式系统互联） 参考模型中一种无连接的传输层协议，提供面向事务的简单、不可靠信息传送服务，其传输的单位是用户数据报。

特征：

  • 无连接
  • 尽最大努力交付
  • 面向报文/事务
  • 没有拥塞控制
  • 支持一对一、一对多、多对一、多对多的交互通信
  • 首部开销小

会话层

建立、管理和终止会话，传输单位为SPDU，主要包括的协议为RPC NFS

表示层

对数据进行翻译、加密和压缩,传输单位为PPDU，主要包括的协议为JPEG ASII

应用层

允许访问OSI环境的手段,传输单位为APDU，主要包括的协议为FTP HTTP DNS

  • DNS（Domain Name System，域名系统）是互联网的一项服务。它作为将域名和 IP 地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS 使用 TCP 和 UDP 端口 53。当前，对于每一级域名长度的限制是 63 个字符，域名总长度则不能超过 253 个字符。

域名 ::= {<三级域名>.<二级域名>.<顶级域名>}，如：blog.huihut.com

  • FTP（File Transfer Protocol，文件传输协议）是用于在网络上进行文件传输的一套标准协议，使用客户/服务器模式，使用 TCP 数据报，提供交互式访问，双向传输。

  • TFTP（Trivial File Transfer Protocol，简单文件传输协议）一个小且易实现的文件传输协议，也使用客户-服务器方式，使用UDPbb数据报，只支持文件传输而不支持交互，没有列目录，不能对用户进行身份鉴定

  • HTTP（HyperText Transfer Protocol，超文本传输协议）是用于从 WWW服务器传输超文本到本地浏览器的传送协议。

  • SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）是一组用于由源地址到目的地址传送邮件的规则，由它来控制信件的中转方式。SMTP 协议属于 TCP/IP 协议簇，它帮助每台计算机在发送或中转信件时找到下一个目的地。

  • TELNET 协议是 TCP/IP 协议族中的一员，是 Internet 远程登陆服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。

  • Socket 建立网络通信连接至少要一对端口号，本质是编程接口（API），对 TCP/IP 的封装，TCP/IP 也要提供可供程序员做网络开发所用的接口，这就是 Socket 编程接口。

WWW （World Wide Web，万维网）

  • 是一个由许多互相链接的超文本组成的系统，通过互联网访问

URL

  • URL（Uniform Resource Locator，统一资源定位符）是因特网上标准的资源的地址（Address）

标准格式：协议类型:[//**服务器地址[:端口号]][/**资源层级UNIX文件路径]文件名[?查询][#片段ID]

完整格式：协议类型:[//[访问资源需要的凭证信息@]服务器地址[:端口号]][/资源层级UNIX文件路径]文件名[?查询][#片段ID]

其中【访问凭证信息@；:端口号；?查询；#片段ID】都属于选填项
如：https://github.com/huihut/interview#cc

HTTP

超文本传输协议是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP 是万维网的数据通信的基础。

方法 意义
OPTIONS 请求一些选项信息，允许客户端查看服务器的性能
GET 请求指定的页面信息，并返回实体主体
HEAD 类似于 get 请求，只不过返回的响应中没有具体的内容，用于获取报头
POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改
PUT 从客户端向服务器传送的数据取代指定的文档的内容
DELETE 请求服务器删除指定的页面
TRACE 回显服务器收到的请求，主要用于测试或诊断

状态码（Status-Code）

  • 1xx：表示通知信息，如请求收到了或正在进行处理

    • 100 Continue：继续，客户端应继续其请求
    • 101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议

  • 2xx：表示成功，如接收或知道了

    • 200 OK: 请求成功
    • 204 No Content 成功状态响应码,表示该请求已经成功了,但是客户端客户不需要离开当前页面。
    • 206 partial content服务器已经正确处理部分GET请求，实现断点续传或同时分片下载，该请求必须包含Range请求头来指示客户端期望得到的范围

  • 3xx：表示重定向，如要完成请求还必须采取进一步的行动

    • 300 multiple choices（可选重定向）:被请求的资源有一系列可供选择的反馈信息，由浏览器/用户自行选择其中一个。
    • 301 moved permanently（永久重定向）：该资源已被永久移动到新位置URL，将来任何对该资源的访问都要使用本响应返回的若干个URI之一。
    • 302 move temporarily (临时重定向)：请求的资源现在临时从不同的URI中获得，
    • 304**：not modified** :如果客户端发送一个待条件的GET请求并且该请求以经被允许，而文档内容未被改变，则返回304,该响应不包含包体（即可直接使用缓存）。

  • 4xx：表示客户的差错，如请求中有错误的语法或不能完成

    • 400 Bad Request: 客户端请求的语法错误，服务器无法理解
    • 401 Unauthorized: 请求要求用户的身份认证
    • 403 Forbidden: 服务器理解请求客户端的请求，但是拒绝执行此请求（权限不够）
    • 404 Not Found: 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置 “您所请求的资源无法找到” 的个性页面
    • 408 Request Timeout: 服务器等待客户端发送的请求时间过长，超时

  • 5xx：表示服务器的差错，如服务器失效无法完成请求

    • 500 Internal Server Error: 服务器内部错误，无法完成请求
    • 502 Bad Gateway: 服务器（不一定是Web服务器）作为网关或代理，以满足客户的要求来访问所请求的URL 。此服务器收到无效响应从上游服务器访问履行它的要求。（服务器错误代码）
    • 503 Service Unavailable: 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中
    • 504 Gateway Timeout: 充当网关或代理的服务器，未及时从远端服务器获取请求

HTTP和HTTPS的区别

HTTP协议和HTTPS协议区别如下：

1）HTTP协议是以明文的方式在网络中传输数据，而HTTPS协议传输的数据则是经过TLS加密后的，HTTPS具有更高的安全性

2）HTTPS在TCP三次握手阶段之后，还需要进行SSL的handshake，协商加密使用的对称加密密钥

3）HTTPS协议需要服务端申请证书，浏览器端安装对应的根证书

4）HTTP协议（默认）端口是80，HTTPS协议端口是443

HTTPS优点

HTTPS传输数据过程中使用密钥进行加密，所以安全性更高

HTTPS协议可以认证用户和服务器，确保数据发送到正确的用户和服务器

HTTPS缺点

HTTPS握手阶段延时较高：由于在进行HTTP会话之前还需要进行SSL握手，因此HTTPS协议握手阶段延时增加

HTTPS部署成本高：一方面HTTPS协议需要使用证书来验证自身的安全性，所以需要购买CA证书；另一方面由于采用HTTPS协议需要进行加解密的计算，占用CPU资源较多，需要的服务器配置或数目高

TCP

TCP建立连接和断开连接的过程：

image-20220326110245071

TCP模型

层次 协议
应用层 Telnet, FTP, E-mail
传输层 TCP, UDP
网络层 IP, ICMP, IGMP
链路层 设备驱动程序及接口卡

TCP的三次握手和四次挥手的过程及原因

三次握手过程如下：

C-> SYN -> S

S-> SYN+ACK ->C

C-> ACK ->S

  1. 客户端发送 SYN 给服务器，说明客户端请求建立连接；
  2. 服务端收到客户端发的 SYN，并回复 SYN+ACK 给客户端（同意建立连接）；
  3. 客户端收到服务端的 SYN+ACK 后，回复 ACK 给服务端（表示客户端收到了服务端发的同意报文）；服务端收到客户端的 ACK，连接已建立，可以数据传输。

TCP 为什么要进行三次握手？

原因：三次握手可以防止（由于网络阻塞）已经失效的连接请求报文突然又传输（当时已经重传了一份）到服务器端导致的服务器资源浪费。

【答案二】因为信道不可靠，而 TCP 想在不可靠信道上建立可靠地传输，那么三次通信是理论上的最小值。（而 UDP 则不需建立可靠传输，因此 UDP 不需要三次握手。）

【答案三】因为双方都需要确认对方收到了自己发送的序列号，确认过程最少要进行三次通信。

image-20220326110753625

四次挥手/释放连接过程如下：

C->FIN->S

S->ACK->C

S->FIN->C

C->ACK->S

  1. 客户端发送 FIN 给服务器，说明客户端不必发送数据给服务器了（请求释放从客户端到服务器的连接）；
  2. 服务器接收到客户端发的 FIN，并回复 ACK 给客户端（同意释放从客户端到服务器的连接）；
  3. 客户端收到服务端回复的 ACK，此时从客户端到服务器的连接已释放（但服务端到客户端的连接还未释放，并且客户端还可以接收数据）；
  4. 服务端继续发送之前没发完的数据给客户端；
  5. 服务端发送 FIN+ACK 给客户端，说明服务端发送完了数据（请求释放从服务端到客户端的连接，就算没收到客户端的回复，过段时间也会自动释放）；
  6. 客户端收到服务端的 FIN+ACK，并回复 ACK 给客户端（同意释放从服务端到客户端的连接）；
  7. 服务端收到客户端的 ACK 后，释放从服务端到客户端的连接。

TCP 为什么要进行四次挥手

  • 为什么要进行四次挥手？为什么 TCP 建立连接需要三次，而释放连接则需要四次？

因为 TCP 是全双工模式，客户端请求关闭连接后，客户端向服务端的连接关闭（一二次挥手），服务端继续传输之前没传完的数据给客户端（数据传输），服务端向客户端的连接关闭（三四次挥手）。所以 TCP 释放连接时服务器的 ACK 和 FIN 是分开发送的（中间隔着数据传输），而 TCP 建立连接时服务器的 ACK 和 SYN 是一起发送的（第二次握手），所以 TCP 建立连接需要三次，而释放连接则需要四次。

四次挥手的原因：由于连接的关闭控制权在应用层，所以被动关闭的一方在接收到FIN包时，TCP协议栈会直接发送一个ACK确认包，优先关闭一端的通信。然后通知应用层，由应用层决定什么时候发送FIN包。应用层可以使用系统调用函数read==0来判断对端是否关闭连接。

  • 为什么 TCP 连接时可以 ACK 和 SYN 一起发送，而释放时则 ACK 和 FIN 分开发送呢？

因为客户端请求释放时，服务器可能还有数据需要传输给客户端，因此服务端要先响应客户端 FIN 请求（服务端发送 ACK），然后数据传输，传输完成后，服务端再提出 FIN 请求（服务端发送 FIN）；而连接时则没有中间的数据传输，因此连接时可以 ACK 和 SYN 一起发送。

  • 为什么客户端释放最后需要 TIME-WAIT 等待2MSL（MSL：报文段最大生存时间）呢？

  1. 为了保证客户端发送的最后一个 ACK 报文能够到达服务端。若未成功到达，则服务端超时重传 FIN+ACK 报文段，客户端再重传 ACK，并重新计时。

  2. 防止已失效的连接请求报文段出现在本连接中。TIME-WAIT 持续 2MSL 可使本连接持续的时间内所产生的所有报文段都从网络中消失，使下次连接中不会出现旧的连接报文段。

TCP拥塞控制

拥塞控制是防止过多的数据注入网络，使得网络中的路由器或者链路过载。流量控制是点对点的通信量控制，而拥塞控制是全局的网络流量整体性的控制。

发送双方都有一个拥塞窗口cwnd。

慢开始

最开始发送方的拥塞窗口为1，由小到大逐渐增大发送窗口和拥塞窗口。每经过一个传输轮次，拥塞窗口cwnd加倍。当cwnd超过慢开始门限，则使用拥塞避免算法，避免cwnd增长过大。

拥塞避免

每经过一个往返时间RTT，cwnd就增长1。

在慢开始和拥塞避免的过程中，一旦发现网络拥塞，就把慢开始门限设为当前值的一半，并且重新设置cwnd为1，重新慢启动（乘法减小，加法增大）。

快重传

接收方每次收到一个失序的报文段后就立即发出重复确认，发送方只要连续收到三个重复确认就立即重传（尽早重传未被确认的报文段）。

快恢复

当发送方连续收到了三个重复确认，就乘法减半（慢开始门限减半），将当前的cwnd设置为慢开始门限，并且采用拥塞避免算法（连续收到了三个重复请求，说明当前网络可能没有拥塞）。采用快恢复算法时，慢开始只在建立连接和网络超时才使用。

image-20220326144645289

拥塞控制达到什么情况的时候开始减慢增长的速度

采用慢开始和拥塞避免算法的时候

  1. 一旦cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度

  2. 一旦出现丢包的情况，就重新进行慢开始，减慢增长速度

采用快恢复和快重传算法的时候

  1. 一旦cwnd>慢开始门限，就采用拥塞避免算法，减慢增长速度

  2. 一旦发送方连续收到了三个重复确认，就采用拥塞避免算法，减慢增长速度

TCP 与 UDP 的区别

  1. TCP 面向连接，UDP 是无连接的；
  2. TCP 提供可靠的服务，也就是说，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP 尽最大努力交付，即不保证可靠交付
  3. TCP 的逻辑通信信道是全双工的可靠信道；UDP 则是不可靠信道
  4. 每一条 TCP 连接只能是点到点的；UDP 支持一对一，一对多，多对一和多对多的交互通信
  5. TCP 面向字节流（可能出现黏包问题），实际上是 TCP 把数据看成一连串无结构的字节流；UDP 是面向报文的（不会出现黏包问题）
  6. UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）
  7. TCP 首部开销20字节；UDP 的首部开销小，只有 8 个字节

TCP 黏包问题

原因

TCP 是一个基于字节流的传输服务，“流” 意味着 TCP 所传输的数据是没有边界的。所以可能会出现两个数据包黏在一起的情况。

解决

  • 发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
  • 包头加上包体长度。包头是定长的 4 个字节，说明了包体的长度。接收对等方先接收包头长度，依据包头长度来接收包体。
  • 在数据包之间设置边界，如添加特殊符号 \r\n 标记。FTP 协议正是这么做的。但问题在于如果数据正文中也含有 \r\n，则会误判为消息的边界。
  • 使用更加复杂的应用层协议。

TCP 流量控制

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

方法：利用可变窗口进行流量控制。

TCP用了哪些措施保证其可靠性

  1. 检验和、序列号、确认应答、超时重传

    数据到达接收方，接收方需要发出一个确认应答，表示已经收到该数据段，并且确认序号会说明了它下一次需要接收的数据序列号。如果发送发迟迟未收到确认应答，那么可能是发送的数据丢失，也可能是确认应答丢失，这时发送方在等待一定时间后会进行重传。这个时间一般是2*RTT(报文段往返时间）+一个偏差值。

  2. 窗口控制与高速重发控制/快速重传（重复确认应答）

    TCP会利用窗口控制来提高传输速度，意思是在一个窗口大小内，不用一定要等到应答才能发送下一段数据，窗口大小就是无需等待确认而可以继续发送数据的最大值。如果不使用窗口控制，每一个没收到确认应答的数据都要重发。

使用窗口控制，如果数据段1001-2000丢失，后面数据每次传输，确认应答都会不停地发送序号为1001的应答，表示我要接收1001开始的数据，发送端如果收到3次相同应答，就会立刻进行重发；但还有种情况有可能是数据都收到了，但是有的应答丢失了，这种情况不会进行重发，因为发送端知道，如果是数据段丢失，接收端不会放过它的，会疯狂向它提醒……

  1. 拥塞控制

    如果把窗口定的很大，发送端连续发送大量的数据，可能会造成网络的拥堵（大家都在用网，你在这狂发，吞吐量就那么大，当然会堵），甚至造成网络的瘫痪。所以TCP在为了防止这种情况而进行了拥塞控制。

慢启动：定义拥塞窗口，一开始将该窗口大小设为1，之后每次收到确认应答（经过一个rtt），将拥塞窗口大小*2。

拥塞避免：设置慢启动阈值，一般开始都设为65536。拥塞避免是指当拥塞窗口大小达到这个阈值，拥塞窗口的值不再指数上升，而是加法增加（每次确认应答/每个rtt，拥塞窗口大小+1），以此来避免拥塞。将报文段的超时重传看做拥塞，则一旦发生超时重传，我们需要先将阈值设为当前窗口大小的一半，并且将窗口大小设为初值1，然后重新进入慢启动过程。

快速重传：在遇到3次重复确认应答（高速重发控制）时，代表收到了3个报文段，但是这之前的1个段丢失了，便对它进行立即重传。然后，先将阈值设为当前窗口大小的一半，然后将拥塞窗口大小设为慢启动阈值+3的大小。这样可以达到：在TCP通信时，网络吞吐量呈现逐渐的上升，并且随着拥堵来降低吞吐量，再进入慢慢上升的过程，网络不会轻易的发生瘫痪。

TCP/IP数据链路层的交互过程

网络层等到数据链层用mac地址作为通信目标，数据包到达网络等准备往数据链层发送的时候，首先会去自己的arp缓存表(存着ip-mac对应关系)去查找改目标ip的mac地址，如果查到了，就讲目标ip的mac地址封装到链路层数据包的包头。如果缓存中没有找到，会发起一个广播：who is ip XXX tell ip XXX,所有收到的广播的机器看这个ip是不是自己的，如果是自己的，则以单拨的形式将自己的mac地址回复给请求的机器.

传递到IP层怎么知道报文该给哪个应用程序，它怎么区分UDP报文还是TCP报文

根据端口区分；

看ip头中的协议标识字段，17是udp，6是tcp。

TCP 超时重传

TCP可靠性中最重要的一个机制是处理数据超时和重传。TCP协议要求在发送端每发送一个报文段，就启动一个定时器并等待确认信息；接收端成功接收新数据后返回确认信息。若在定时器超时前数据未能被确认，TCP就认为报文段中的数据已丢失或损坏，需要对报文段中的数据重新组织和重传。

请问server端监听端口，但还没有客户端连接进来，此时进程处于什么状态？

这个需要看服务端的编程模型，如果如上一个问题的回答描述的这样，则处于阻塞状态，如果使用了epoll,select等这样的io复用情况下，处于运行状态。

浏览器中输入URL发生了什么

  1. 浏览器的地址栏输入URL并按下回车。

  2. DNS查询：查找当前URL的DNS缓存记录，DNS解析URL对应的IP。

  3. 根据IP建立TCP连接（三次握手）。

  4. HTTP发起请求：完整的包含请求起始行、请求主体和请求头部三部分。

  5. 服务器处理请求，浏览器接收HTTP响应。

  6. render渲染页面，构建DOM树。

  7. 关闭TCP连接（四次挥手）。

浏览器要将URL解析为IP地址，解析域名就要用到DNS协议【应用层】，首先主机会查询DNS的缓存，如果没有就给本地DNS发送查询请求。

DNS查询分为两种方式，一种是递归查询，一种是迭代查询。如果是迭代查询，本地的DNS服务器，向根域名服务器发送查询请求，根域名服务器告知该域名的一级域名服务器，然后本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址。DNS服务器是基于UDP的，因此会用到UDP协议。【传输层】2个常用的命令dig和nslookup。

得到IP地址后，浏览器就要与服务器建立一个http连接。因此要用到http协议【应用层】，http协议报文格式上面已经提到。http生成一个get请求报文，将该报文传给TCP层处理，所以还会用到TCP协议。如果采用https还会使用https协议先对http数据进行加密。TCP层如果有需要先将HTTP数据包分片，分片依据路径MTU和MSS。TCP的数据包然后会发送给IP层，用到IP协议。【网络层】IP层通过路由选路，一跳一跳发送到目的地址。当然在一个网段内的寻址是通过以太网协议实现(也可以是其他物理层协议，比如PPP，SLIP)，以太网协议需要直到目的IP地址的物理地址，有需要ARP协议。

服务器在收到浏览器发送的HTTP请求之后，会将收到的HTTP报文封装成HTTP的Request对象，并通过不同的Web服务器进行处理，处理完的结果以HTTP的Response对象返回，主要包括状态码，响应头，响应报文三个部分。

浏览器按顺序解析html文件，构建DOM树，在解析到外部的css和js文件时，向服务器发起请求下载资源，若是下载css文件，则解析器会在下载的同时继续解析后面的html来构建DOM树；若在下载js文件，解析器会停止对html的解析，这就出现了js阻塞问题。

其中：

  1. DNS协议，http协议，https协议属于应用层

应用层是体系结构中的最高层。应用层确定进程之间通信的性质以满足用户的需要。这里的进程就是指正在运行的程序。应用层不仅要提供应用进程所需要的信息交换和远地操作，而且还要作为互相作用的应用进程的用户代理，来完成一些为进行语义上有意义的信息交换所必须的功能。应用层直接为用户的应用进程提供服务。

  1. TCP/UDP属于传输层

传输层的任务就是负责主机中两个进程之间的通信。因特网的传输层可使用两种不同协议：即面向连接的传输控制协议TCP，和无连接的用户数据报协议UDP。面向连接的服务能够提供可靠的交付，但无连接服务则不保证提供可靠的交付，它只是“尽最大努力交付”。这两种服务方式都很有用，备有其优缺点。在分组交换网内的各个交换结点机都没有传输层。

  1. IP协议，ARP协议属于网络层

网络层负责为分组交换网上的不同主机提供通信。在发送数据时，网络层将运输层产生的报文段或用户数据报封装成分组或包进行传送。在TCP/IP体系中，分组也叫作IP数据报，或简称为数据报。网络层的另一个任务就是要选择合适的路由，使源主机运输层所传下来的分组能够交付到目的主机。

  1. 数据链路层

当发送数据时，数据链路层的任务是将在网络层交下来的IP数据报组装成帧，在两个相邻结点间的链路上传送以帧为单位的数据。每一帧包括数据和必要的控制信息（如同步信息、地址信息、差错控制、以及流量控制信息等）。控制信息使接收端能够知道—个帧从哪个比特开始和到哪个比特结束。控制信息还使接收端能够检测到所收到的帧中有无差错。

  1. 物理层

物理层的任务就是透明地传送比特流。在物理层上所传数据的单位是比特。传递信息所利用的一些物理媒体，如双绞线、同轴电缆、光缆等，并不在物理层之内而是在物理层的下面。因此也有人把物理媒体当做第0层。

HTTP 长连接和短连接

什么是长连接、短连接

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

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

TCP短连接

模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。

TCP长连接

我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

TCP的保活功能主要为服务器应用提供。如果客户端已经消失而连接未断开，则会使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，此时服务器将永远等待客户端的数据。保活功能就是试图在服务端器端检测到这种半开放的连接。

如果一个给定的连接在两小时内没有任何动作，服务器就向客户发送一个探测报文段，根据客户端主机响应探测4个客户端状态：

客户主机依然正常运行，且服务器可达。此时客户的TCP响应正常，服务器将保活定时器复位。

客户主机已经崩溃，并且关闭或者正在重新启动。上述情况下客户端都不能响应TCP。服务端将无法收到客户端对探测的响应。服务器总共发送10个这样的探测，每个间隔75秒。若服务器没有收到任何一个响应，它就认为客户端已经关闭并终止连接。

客户端崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。

客户机正常运行，但是服务器不可达。这种情况与第二种状态类似。

长连接和短连接的优点和缺点

由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户端适合使用长连接。在长连接的应用场景下，client端一般不会主动关闭连接，当client与server之间的连接一直不关闭，随着客户端连接越来越多，server会保持过多连接。这时候server端需要采取一些策略，如关闭一些长时间没有请求发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件允许则可以限制每个客户端的最大长连接数，这样可以完全避免恶意的客户端拖垮整体后端服务。

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

长连接和短连接的产生在于client和server采取的关闭策略。

长连接短连接操作过程

短连接的操作步骤是：

建立连接——数据传输——关闭连接 … 建立连接——数据传输——关闭连接

长连接的操作步骤是：

建立连接——数据传输…（保持连接）… 数据传输——关闭连接

什么时候用长连接，短连接

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站成千上万甚至上亿客户端的连接用短连接会更省一些资源. 所以并发量大，但每个用户无需频繁操作情况下需用短连好。

HTTP的长连接和短连接本质上是TCP长连接和短连接

HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。

如何理解HTTP协议是无状态的

HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。也就是说，打开一个服务器上的网页和上一次打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。

HTTP, TCP的Keep-alive

我们知道Http协议采用“请求-应答”模式，当使用普通模式，即非Keep-Alive模式时，每个请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接；当使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。
http1.0中默认是关闭的，需要在http头加入”Connection: Keep-Alive”，才能启用Keep-Alive；
http 1.1中默认启用Keep-Alive，如果加入”Connection: close “才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep- Alive连接就看服务器设置情况。

Keep-Alive timeout：

Httpd守护进程，一般都提供了keep-alive timeout时间设置参数。比如nginx的keepalive_timeout，和Apache的KeepAliveTimeout。这个keepalive_timout时间值意味着：一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。
当httpd守护进程发送完一个响应后，理应马上主动关闭相应的tcp连接，设置 keepalive_timeout后，httpd守护进程会想说：”再等等吧，看看浏览器还有没有请求过来”，这一等，便是keepalive_timeout时间。如果守护进程在这个等待的时间里，一直没有收到浏览器发过来http请求，则关闭这个http连接。

开启Keep-Alive的优缺点：

优点：Keep-Alive模式更加高效，因为避免了连接建立和释放的开销。
缺点：长时间的Tcp连接容易导致系统资源无效占用，浪费系统资源。

Tcp的Keepalive：

连接建立之后，如果客户端一直不发送数据，或者隔很长时间才发送一次数据，当连接很久没有数据报文传输时如何去确定对方还在线，到底是掉线了还是确实没有数据传输，连接还需不需要保持，这种情况在TCP协议设计中是需要考虑到的。
TCP协议通过一种巧妙的方式去解决这个问题，当超过一段时间之后，TCP自动发送一个数据为空的报文（侦测包）给对方，如果对方回应了这个报文，说明对方还在线，连接可以继续保持，如果对方没有报文返回，并且重试了多次之后则认为链接丢失，没有必要保持连接。

tcp keep-alive是TCP的一种检测TCP连接状况的保鲜机制。tcp keep-alive保鲜定时器，支持三个系统内核配置参数：
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 1800
keepalive是TCP保鲜定时器，当网络两端建立了TCP连接之后，闲置（双方没有任何数据流发送往来）了tcp_keepalive_time后，服务器就会尝试向客户端发送侦测包，来判断TCP连接状况(有可能客户端崩溃、强制关闭了应用、主机不可达等等)。如果没有收到对方的回答(ack包)，则会在 tcp_keepalive_intvl后再次尝试发送侦测包，直到收到对方的ack,如果一直没有收到对方的ack,一共会尝试 tcp_keepalive_probes次，每次的间隔时间在这里分别是15s, 30s, 45s, 60s, 75s。如果尝试tcp_keepalive_probes,依然没有收到对方的ack包，则会丢弃该TCP连接。TCP连接默认闲置时间是2小时，一般设置为30分钟足够了。

网络编程

Socket

Socket 中的 read()、write() 函数

ssize_t read(int fd, void *buf, size_t count);

ssize_t write(int fd, const void *buf, size_t count);

read()

  • read 函数是负责从 fd 中读取内容。
  • 当读成功时，read 返回实际所读的字节数。
  • 如果返回的值是 0 表示已经读到文件的结束了，小于 0 表示出现了错误。
  • 如果错误为 EINTR 说明读是由中断引起的；如果是 ECONNREST 表示网络连接出了问题。

write()

  • write 函数将 buf 中的 nbytes 字节内容写入文件描述符 fd。
  • 成功时返回写的字节数。失败时返回 -1，并设置 errno 变量。
  • 在网络程序中，当我们向套接字文件描述符写时有俩种可能。
  • （1）write 的返回值大于 0，表示写了部分或者是全部的数据。
  • （2）返回的值小于 0，此时出现了错误。
  • 如果错误为 EINTR 表示在写的时候出现了中断错误；如果为 EPIPE 表示网络连接出现了问题（对方已经关闭了连接）。

Socket 中 TCP 的三次握手建立连接

我们知道 TCP 建立连接要进行 “三次握手”，即交换三个分组。大致流程如下：

  1. 客户端向服务器发送一个 SYN J
  2. 服务器向客户端响应一个 SYN K，并对 SYN J 进行确认 ACK J+1
  3. 客户端再想服务器发一个确认 ACK K+1

只有就完了三次握手，但是这个三次握手发生在 Socket 的那几个函数中呢？

  1. 当客户端调用 connect 时，触发了连接请求，向服务器发送了 SYN J 包，这时 connect 进入阻塞状态；
  2. 服务器监听到连接请求，即收到 SYN J 包，调用 accept 函数接收请求向客户端发送 SYN K ，ACK J+1，这时 accept 进入阻塞状态；
  3. 客户端收到服务器的 SYN K ，ACK J+1 之后，这时 connect 返回，并对 SYN K 进行确认；
  4. 服务器收到 ACK K+1 时，accept 返回，至此三次握手完毕，连接建立。

Socket 中 TCP 的四次握手释放连接

上面介绍了 socket 中 TCP 的三次握手建立过程，及其涉及的 socket 函数。现在我们介绍 socket 中的四次握手释放连接的过程：

  1. 某个应用进程首先调用 close 主动关闭连接，这时 TCP 发送一个 FIN M；
  2. 另一端接收到 FIN M 之后，执行被动关闭，对这个 FIN 进行确认。它的接收也作为文件结束符传递给应用进程，因为 FIN 的接收意味着应用进程在相应的连接上再也接收不到额外数据；
  3. 一段时间之后，接收到文件结束符的应用进程调用 close 关闭它的 socket。这导致它的 TCP 也发送一个 FIN N；
  4. 接收到这个 FIN 的源发送端 TCP 对它进行确认。

这样每个方向上都有一个 FIN 和 ACK。


实习      C++ 面经

本博客所有文章除特别声明外，均采用 CC BY-SA 3.0协议 。转载请注明出处！