计算机网络

什么是ISO 七层模型和 TCP/IP 四层模型？

OSI模型：七层模型，分别是物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。
简化合并为四层模型：应用层、传输层、网络层、网络接口层（各层之间的模型、协议统称为：TCP/IP协议簇）

TCP/IP模型合并了OSI模型的应用层、表示层和会话层，将OSI模型的数据链路层和物理层合并为网络访问层
各层模型对应TCP/IP协议栈中的协议以及各层协议之间的关系：

• DNS协议是建立在TCP和UDP协议的基础上
• FTP、HTTP、TELNET协议建立在TCP协议的基础上
• NTP、TFTP、SNMP建立在UDP协议的基础上
• TCP、UDP协议又建立在IP协议的基础上

ping 可以说是ICMP的最著名的应用，ICMP和IP一样，是网络层的协议

常见互联网协议

layer	protocols
应用层	BGP、DHCP、DNS、FTP、HTTP、HTTPS、IMAP、LDAP、MGCP、MQTT、NNTP、NTP、POP、ONC/RPC、RTP、RTSP、SIP、SMTP、SNMP、SSH、Telnet、XMPP
传输层	TCP、UDP、TLS／SSL、DCCP、SCTP、RSVP
网络层	IP (IPv4、IPv6)、ICMP、ICMPv6、ECN、IGMP、OSPF、IPsec、RIP
链接层	ARP、NDP、Tunnels L2TP、PPP、MAC (Ethernet｜DSL｜ISDN｜FDDI)

应用层协议常用端口

TCP/IP

TCP/IP 与 HTTP 有什么关系？

• TCP/IP 协议不仅仅指的是 TCP 和 IP 两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇， 只是因为在TCP/IP协议中TCP协议和IP协议最具代表性，所以被称为TCP/IP协议。
• HTTP是应用层协议，主要解决如何包装数据。
• “IP”代表网际协议，TCP 和 UDP 使用该协议从一个网络传送数据包到另一个网络。把IP想像成一种高速公路，它允许其它协议在上面行驶并找到到其它电脑的出口。TCP和UDP是高速公路上的“卡车”，它们携带的货物就是像HTTP，文件传输协议FTP这样的协议等。

TCP协议与UDP协议的区别？

1. TCP 与 UDP都属于传输层协议。
   |TCP（Transmission Control Protocol，传输控制协议） | 面向连接的单播协议，在发送数据前，通信双方必须在彼此间建立一条连接。一个TCP连接必须有三次握手、四次挥手。 |
   |–|--|
   |UDP（User Data Protocol，用户数据报协议） | 非连接的协议，传输数据之前源端和终端不建立连接， 当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上 |
2. UDP首部
   
3. TCP首部
   

• 序号 ：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100字节，那么下一个报文段的序号应为 401。
• 确认号 ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
• 数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上是首部的长度。
• 确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把ACK 置 1。
• 同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
• 终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
• 窗口 ：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。

UDP 协议中的长度和校验码可以被省略么？为什么？

• 除了 IP 协议还有其他的协议可以传输 UDP 包[1]
• UDP 的内容是自包含的，TCP 一般都是都是数据流的一部分[2]
• 把长度作为校验和的一部分, 用来进行差错校验

除了 UDP 和 TCP 协议，其他基于 IP 的传输层协议有没有端口号的概念？

主要是看是否需要在一个主机上跑多个使用这个协议的程序，像 ICMP 这种没必要跑多个就没有端口的概念，类似 TCP、UDP 这种需要跑多个的就需要端口号来区分。

详细介绍一下 TCP 的三次握手、四次挥手

• SYN_SEND/RECV 为什么要第三次握手？
  • 第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。
  • 第三次握手开始，可以携带数据包
• 为什么四次挥手？
  • TCP 协议是全双工的，也就是说客户端和服务端都可以发起断开连接。两边各发起一次断开连接的申请，加上各自的两次确认，看起来就像执行了四次挥手。
  • 当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。关闭时当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，之后再回复FIN报文
• CLOSE_WAIT
  对方主动关闭连接或者网络异常导致连接中断，这时我方的状态会变成CLOSE_WAIT，此时我方要调用close()来使得连接正确关闭。
• TIME_WAIT
  • 我方主动调用close()断开连接，收到对方确认后状态变为TIME_WAIT。
  • TCP协议规定TIME_WAIT状态会一直持续2MSL(即两倍的分段最大生存期)，以此来确保[1. 接受方收到ACK 2. 网络中本链接产生的报文消失]。
  • 处于TIME_WAIT状态的连接占用的资源不会被内核释放，所以作为服务器，在可能的情况下，尽量不要主动断开连接，以减少TIME_WAIT状态造成的资源浪费。

详细讲一下TCP的滑动窗口、流量控制和拥塞控制

TCP通过以下方式进行保证传输的可靠性：

• 数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时TCP发送数据端超时后会重发数据；
• 对失序数据包重排序：既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段的到达也可能会失序。TCP将对失序数据进行重新排序，然后才交给应用层；
• 丢弃重复数据：对于重复数据，能够丢弃重复数据；
• 应答机制： 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
• 超时重发：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
• 流量控制： TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP使用的流量控制协议是可变大小的滑动窗口协议。

滑动窗口

流量控制

• 原因：接收方有一块接收缓存，当数据来到时会先把数据放到缓存中，上层应用等缓存中有数据时就会到缓存中取数据。假如发送方没有限制地不断地向接收方发送数据，接收方的应用程序又没有及时把接收缓存中的数据读走，就会出现缓存溢出，数据丢失的现象，为了解决这个问题，我们引入流量控制窗口。
• 接收方在响应 ACK 的时候把这个窗口的值放在 TCP window_size字段带给发送方，发送方就能知道接收方的接收缓存还有多大的空间，进而设置滑动窗口的大小

拥塞控制

拥塞控制和流量控制不同，前者是一个全局性的过程（网络中的路由器或链路），而后者指点对点通信量的控制（发送方 => 接收方）。

• 慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;
• 拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
• 快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连 收到三个重复确认 就应当 立即重传 对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
• 快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到 三个重复确认 时，就执行“乘法减小”算法，把 ssthresh门限减半 ，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

故障排查

服务器出现了大量CLOSE_WAIT状态如何解决

大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭连接，而我方忙于读或写没有及时关闭连接，需要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。

SYN超时，洪泛攻击，以及解决策略

什么 SYN 是洪泛攻击？

• 在 TCP 的三次握手机制的第一步中，客户端会向服务器发送 SYN 报文段。服务器接收到 SYN 报文段后会为该TCP分配缓存和变量

• TCB(TCP 传输控制块) 是一种包含一个连接所有信息的传输协议数据结构，通常一个TCB至少280字节

• 如果攻击分子大量地往服务器发送 SYN 报文段 ，服务器的连接资源终将被耗尽，分配过多的TCB导致内核内存溢出无法继续服务。

• 为了避免这种内存耗尽，操作系统通常给监听接口关联了一个 "backlog"队列 参数，它同时维护连接的TCB上限数量和SYN-RECEIVED状态。尽管这种方案使主机的可用内存免遭攻击，但是backlog队列本身就带来了一个(小的)受攻击源。当backlog中没有空间时，就不可能再响应新的连接请求，除非TCB能被回收或者从SYN-RECIEVE状态中移除。

• 试图发送足够多的SYN包而耗尽backlog是TCP SYN洪泛的目的
  
  解决策略：

• 当服务器接受到 SYN 报文段时，不直接为该 TCP 分配资源，而只是打开一个半开的套接字。接着会使用 SYN 报文段的源Id，目的Id，端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie，并 把 cookie 作为序列号 响应给客户端。

• 如果客户端是正常建立连接，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源Id，目的Id，端口号以及秘密函数计算出一个结果，如果 结果的值 + 1等于确认字段 的值，则证明是刚刚请求连接的客户端，这时候才为该 TCP 分配资源

这样一来就不会为恶意攻击的 SYN 报文段分配资源空间，避免了攻击。

HTTP

HTTP1.0、HTTP1.1、HTTP2.0 的区别

HTTP/0.9
HTTP协议的最初版本，功能简陋，仅支持 GET 方法，并且仅能请求访问 HTML 格式的资源

HTTP/1.0

• 增加了请求方式 POST 和 HEAD
• Content-Type：支持多种数据格式，text/html、image/jpeg等
• cache：当客户端在规定时间内访问同一网站，直接访问cache
• HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。
• 状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）等
• 每次TCP连接只能发送一个请求，下一个请求需要再次建立TCP连接，不支持keepalive

HTTP/1.0+

• 持久的 keep-alive 连接：声明Connection: keep-alive
• 虚拟主机支持，以及代理连接支持

HTTP/1.1

• TCP连接默认不关闭，不用声明Connection: keep-alive
• pipelining：同一个TCP连接里，客户端可以同时发送多个请求
• 新增方法：PUT、 PATCH、 OPTIONS、 DELETE
• http协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度。

HTTP2

• 彻底的二进制协议：头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
• 复用TCP连接：在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了队头堵塞的问题,此双向的实时通信称为多工（ Multiplexing）。
• 服务器推送： 允许服务器未经请求，主动向客户端发送资源
• 头信息压缩机制（ header compression） ：头信息使用gzip或compress压缩后再发送。

URI 和 URL

URi：Uniform Resource Identifier，统一资源标识符；e.g 相对URi：<img src="../icons/logo.png" alt="logo">
URL：Uniform Resource Locator，统一资源定位符；e.g. http://somesite.com/html/top
URN：Uniform Resource Name，统一资源名称。e.g. urn:isbn:0-486-27557-4，这个是一本书的isbn

GET和POST的区别

• 浏览器的GET和POST
  • GET没有副作用，可以多次执行，或缓存；POST有副作用，不幂等的，不能缓存
  • 说“GET请求没有body，只有url，请求数据放在url的querystring中；POST请求的数据在body中“。但这种情况仅限于浏览器发请求的场景。
• 接口中的GET和POST
  • 【GET】 + 【资源定位符】被专用于获取资源或者资源列表（e.g ES的GET可以有body）
  • 【POST】+ 【资源定位符】则用于“创建一个资源”
• 安全性
  • 无论是GET还是POST都不够安全， HTTP本身是明文协议。每个HTTP请求和返回的每个byte都会在网络上明文传播，不管是url，header还是body。
  • 如果请求要经过不信任的公网，避免泄密的唯一手段就是https
  • 安全是一个巨大的主题，比如返回私密数据的mask，XSS，CSRF，跨域安全，前端加密，钓鱼，salt，get和post只是一小部分
• 编码
  • body：Content-Type会同时定义请求body的格式application/x-www-form-urlencoded和字符编码（UTF-8）
  • URL：一个ASCII的子集*[a-zA-Z0-9$-_.+!’(),] 可以“不经编码”在url中使用，其他字符需要转换成URL可用字符（Percent Encoding），但是字符集编码本身没有被规定，取决于浏览器内核版本，一个带中文的url可能是GBK（IE8）或者UTF8（chrome），导致后端认不出来
• POST需要发两个请求吗？
  • 不一定，第一次（返回 100 Continued 的）只是希望先拿到请求头部，查看用户是不是有权限上传，文件名是不是符合规范等。如果不符合，就不再处理请求体的数据了，直接丢弃。而不用等到整个请求都处理完了再拒绝。
  • 如果刚好请求体的数据也不多，那么一次性全部发给服务器可能反而更好。这种优化是一种客户端实现细节，和get post本身无关
• 什么算请求体
  • 业务角在意的其实是【请求】和【返回】。
  • 当我们在说“请求头”这三个字时，也许实际的意思是【请求】，因为仅仅用到【HTTP的请求头】（比如大部分GET请求）
  • 也可能需要的【HTTP请求头】+【HTTP请求体】（比如用POST实现上传文件）。
• URL的长度
  • URL长度有可能达到1000个bytes以上，就必须使用body来传输数据。
  • 算url长度时，1个汉字字符经过UTF8编码 + percent encoding后会变成9个字节

HTTP状态码

• 1xx：表明服务端接收了客户端请求，客户端继续发送请求；
• 2xx：客户端发送的请求被服务端成功接收并成功进行了处理；
• 3xx：服务端给客户端返回用于重定向的信息；
• 4xx：客户端的请求有非法内容；
• 5xx：服务端未能正常处理客户端的请求而出现意外错误。
• 100 Continue
• 200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
• 204 No Content：表示客户端发送给客户端的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）
• 206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。
• 301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
• 302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
• 303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源
• 304 Not Modified：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求为满足条件的情况下返回改状态码；
• 400 Bad Request:表示请求报文中存在语法错误；
• 401 Unauthorized：经许可，需要通过HTTP认证；
• 403 Forbidden：服务器拒绝该次访问（访问权限出现问题）
• 404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；
• 499 “client has closed connection”，nginx 自定义的 code：客户端请求等待链接已经关闭，这很有可能是因为服务器端处理的时间过长，客户端等得“不耐烦”了。还有一种原因是两次提交post过快就会出现499。
• 500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；
• 502 Bad Gateway：服务器作为网关需要得到一个处理这个请求的响应，但是得到一个错误的响应。
• 503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；
• 504 Gateway Timeout

介绍HTTPS，SSL/TLS

HTTPS和HTTP的区别主要如下：

协议	证书	端口	状态
https	需要到ca申请证书	443	由SSL+HTTP协议构建的，可进行加密传输、身份认证
http	不需要	80	无状态

对称加密	加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，任何人拿到密钥都可以解密，所以安全性不高。
非对称加密	使用了一对密钥，公钥与私钥，客户端用公钥加密，服务端用私钥解密。所以安全性高，但加密与解密速度慢。

如何保证公钥不被篡改？
解决方法：将公钥放在 数字证书 CA 中。只要证书是可信的，公钥就是可信的。
为什么服务端要发送证书给客户端
互联网有太多的服务需要使用证书来验证身份，以至于客户端(操作系统或浏览器等)无法内置所有证书，需要通过服务端将证书发送给客户端，客户端内置了所有受信任CA的证书。
客户端为什么要验证接收到的证书
防止中间人攻击
客户端<------------攻击者<------------服务端 伪造证书 拦截请求
客户端如何验证接收到的证书

• Bob客户端内置了所有受信任CA的证书。CA对Susan的公钥（和其他信息）数字签名后生成证书。
• Susan将证书发送给Bob后，Bob通过CA证书的公钥验证证书签名。
• Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任链（Chain Of Trust）就是这样形成的。
• Bob客户端内置的是CA的根证书(Root Certificate)，HTTPS协议中服务器会发送证书链（Certificate Chain）给客户端

cookie和session

因为HTTP无状态，cookie和session都是用来保存 当前会话状态 数据的。
cookie 是浏览器的一种缓存机制，将会话保存在客户端
session 一种会话机制，把会话保存在服务端
在许多 web 应用中，session 机制就是通过 cookie 来实现。e.g. “cookie: session=xxx;”
session实现 也有别的途径，比如bearer auth、JWT、userToken等

FAQ

Web 页面请求过程

• DHCP 配置主机信息
  • 主机生成一个 DHCP 请求报文，并将这个报文放入具有目的端口 67 和源端口 68 的 UDP 报文段中。
  • 该报文段则被放入在一个具有广播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 数据报中。
  • 该数据报则被放置在 MAC 帧中，该帧具有目的地址 FF:FF:FF:FF:FF:FF，将广播到与交换机连接的所有设备。
  • 连接在交换机的 DHCP 服务器收到广播帧之后，不断地向上分解得到 IP 数据报、UDP 报文段、DHCP 请求报文，之后生成 DHCP ACK 报文，该报文包含以下信息：IP 地址、DNS 服务器的 IP 地址、默认网关路由器的 IP地址和子网掩码。该报文被放入 UDP 报文段中，UDP 报文段有被放入 IP 数据报中，最后放入 MAC 帧中。
  • 该帧的目的地址是请求主机的 MAC 地址，因为交换机具有自学习能力，之前主机发送了广播帧之后就记录了
  • MAC 地址到其转发接口的交换表项，因此现在交换机就可以直接知道应该向哪个接口发送该帧。
  • 主机收到该帧后，不断分解得到 DHCP 报文。之后就配置它的 IP 地址、子网掩码和 DNS 服务器的 IP 地址，并在其 IP 转发表中安装默认网关。
• ARP解析MAC地址
• DNS解析域名
• HTTP请求页面

XSS 攻击

XSS 是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。
XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

IP地址的分类

A、B、C是基本类，D、E类作为多播和保留使用
A类地址：以0开头，第一个字节范围：0~127；
B类地址：以10开头，第一个字节范围：128~191；
C类地址：以110开头，第一个字节范围：192~223；
D类地址：以1110开头，第一个字节范围为224~239；
E类地址：以1111开头，保留地址

标签：协议,请求,IP,报文,TCP,速记,计算机网络,面试,客户端
来源： https://blog.csdn.net/weisman2/article/details/115559003