计算机网络

请说一下socket网络编程中客户端和服务端用到哪些函数？

参考回答

服务器端函数：

（1）socket创建一个套接字

（2）bind绑定ip和port

（3）listen使套接字变为可以被动链接

（4）accept等待客户端的链接

（5）write/read接收发送数据

（6）close关闭连接
客户端函数：

（1）创建一个socket，用函数socket()

（2）bind绑定ip和port

（3）连接服务器，用函数connect()

（4）收发数据，用函数send()和recv()，或read()和write()

（5）close关闭连接

TCP 半连接队列和全连接队列

在 TCP 三次握手的时候，Linux 内核会维护两个队列，分别是：

半连接队列，也称 SYN 队列；
全连接队列，也称 accept 队列；

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到 accept 队列，等待进程调用 accept 函数时把连接取出来。

没有 accept，能建立 TCP 连接吗？

答案：可以的。

accpet 系统调用并不参与 TCP 三次握手过程，它只是负责从 TCP 全连接队列取出一个已经建立连接的 socket，用户层通过 accpet 系统调用拿到了已经建立连接的 socket，就可以对该 socket 进行读写操作了。

没有 listen，能建立 TCP 连接吗？

答案：可以的。

客户端是可以自己连自己的形成连接（TCP自连接），也可以两个客户端同时向对方发出请求建立连接（TCP同时打开），这两个情况都有个共同点，就是没有服务端参与，也就是没有 listen，就能 TCP 建立连接。

如何优化 TCP?

TCP 三次握手的性能提升；

客户端的优化

当客户端发起 SYN 包时，可以通过 tcp_syn_retries 控制其重传的次数。

服务端的优化

当服务端 SYN 半连接队列溢出后，会导致后续连接被丢弃，可以通过 netstat -s 观察半连接队列溢出的情况，如果 SYN 半连接队列溢出情况比较严重，可以通过 tcp_max_syn_backlog、somaxconn、backlog 参数来调整 SYN 半连接队列的大小。

服务端回复 SYN+ACK 的重传次数由 tcp_synack_retries 参数控制。如果遭受 SYN 攻击，应把 tcp_syncookies 参数设置为 1，表示仅在 SYN 队列满后开启 syncookie 功能，可以保证正常的连接成功建立。

服务端收到客户端返回的 ACK，会把连接移入 accpet 队列，等待进行调用 accpet() 函数取出连接。

可以通过 ss -lnt 查看服务端进程的 accept 队列长度，如果 accept 队列溢出，系统默认丢弃 ACK，如果可以把 tcp_abort_on_overflow 设置为 1 ，表示用 RST 通知客户端连接建立失败。

如果 accpet 队列溢出严重，可以通过 listen 函数的 backlog 参数和 somaxconn 系统参数提高队列大小，accept 队列长度取决于 min(backlog, somaxconn)。

绕过三次握手

TCP Fast Open 功能可以绕过三次握手，使得 HTTP 请求减少了 1 个 RTT 的时间，Linux 下可以通过 tcp_fastopen 开启该功能，同时必须保证服务端和客户端同时支持。
TCP 四次挥手的性能提升；
针对 TCP 四次挥手的优化，我们需要根据主动方和被动方四次挥手状态变化来调整系统 TCP 内核参数。

主动方的优化

主动发起 FIN 报文断开连接的一方，如果迟迟没收到对方的 ACK 回复，则会重传 FIN 报文，重传的次数由 tcp_orphan_retries 参数决定。

当主动方收到 ACK 报文后，连接就进入 FIN_WAIT2 状态，根据关闭的方式不同，优化的方式也不同：
- 如果这是 close 函数关闭的连接，那么它就是孤儿连接。如果 tcp_fin_timeout 秒内没有收到对方的 FIN 报文，连接就直接关闭。同时，为了应对孤儿连接占用太多的资源，tcp_max_orphans 定义了最大孤儿连接的数量，超过时连接就会直接释放。
- 反之是 shutdown 函数关闭的连接，则不受此参数限制；
当主动方接收到 FIN 报文，并返回 ACK 后，主动方的连接进入 TIME_WAIT 状态。这一状态会持续 1 分钟，为了防止 TIME_WAIT 状态占用太多的资源，tcp_max_tw_buckets 定义了最大数量，超过时连接也会直接释放。

当 TIME_WAIT 状态过多时，还可以通过设置 tcp_tw_reuse 和 tcp_timestamps 为 1 ，将 TIME_WAIT 状态的端口复用于作为客户端的新连接，注意该参数只适用于客户端。

被动方的优化

被动关闭的连接方应对非常简单，它在回复 ACK 后就进入了 CLOSE_WAIT 状态，等待进程调用 close 函数关闭连接。因此，出现大量 CLOSE_WAIT 状态的连接时，应当从应用程序中找问题。

当被动方发送 FIN 报文后，连接就进入 LAST_ACK 状态，在未等到 ACK 时，会在 tcp_orphan_retries 参数的控制下重发 FIN 报文
TCP 数据传输的性能提升
本节针对 TCP 优化数据传输的方式，做了一些介绍。

TCP 可靠性是通过 ACK 确认报文实现的，又依赖滑动窗口提升了发送速度也兼顾了接收方的处理能力。

可是，默认的滑动窗口最大值只有 64 KB，不满足当今的高速网络的要求，要想提升发送速度必须提升滑动窗口的上限，在 Linux 下是通过设置 tcp_window_scaling 为 1 做到的，此时最大值可高达 1GB。

滑动窗口定义了网络中飞行报文的最大字节数，当它超过带宽时延积时，网络过载，就会发生丢包。而当它小于带宽时延积时，就无法充分利用网络带宽。因此，滑动窗口的设置，必须参考带宽时延积。

内核缓冲区决定了滑动窗口的上限，缓冲区可分为：发送缓冲区 tcp_wmem 和接收缓冲区 tcp_rmem。

Linux 会对缓冲区动态调节，我们应该把缓冲区的上限设置为带宽时延积。发送缓冲区的调节功能是自动打开的，而接收缓冲区需要把 tcp_moderate_rcvbuf 设置为 1 来开启。其中，调节的依据是 TCP 内存范围 tcp_mem。

但需要注意的是，如果程序中的 socket 设置 SO_SNDBUF 和 SO_RCVBUF，则会关闭缓冲区的动态整功能，所以不建议在程序设置它俩，而是交给内核自动调整比较好。

有效配置这些参数后，既能够最大程度地保持并发性，也能让资源充裕时连接传输速度达到最大值

如何基于 UDP 协议实现可靠传输？

升级 TCP 的工作很困难；
TCP 建立连接的延迟；
TCP 存在队头阻塞问题；
网络迁移需要重新建立 TCP 连接；

QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能

2.61 简述网络七层参考模型，每一层的作用？

TCP/IP 网络通常是由上到下分成 4 层，分别是应用层，传输层，网络层和网络接口层。

再给大家贴一下每一层的封装格式：

网络接口层的传输单位是帧（frame），IP 层的传输单位是包（packet），TCP 层的传输单位是段（segment），HTTP 的传输单位则是消息或报文（message）。但这些名词并没有什么本质的区分，可以统称为数据包。

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.	数据链路层

简述静态路由和动态路由

参考回答

静态路由是由系统管理员设计与构建的路由表规定的路由。适用于网关数量有限的场合，且网络拓朴结构不经常变化的网络。其缺点是不能动态地适用网络状况的变化，当网络状况变化后必须由网络管理员修改路由表。
动态路由是由路由选择协议而动态构建的，路由协议之间通过交换各自所拥有的路由信息实时更新路由表的内容。动态路由可以自动学习网络的拓朴结构，并更新路由表。其缺点是路由广播更新信息将占据大量的网络带宽。

跟团游（静态路由）：导游提供的路线为北京-南京-深圳-三亚。
自由行（动态路由）：出发于北京，终点在三亚，途径哪里我们具体情况具体分析。


静态路由是由网络管理员手动创建的路由，路由器的路由表条目由网络管理员手动填充。而且静态路由是固定的，不会随着网络的改变而变化。
静态路由的优点是路由器之间不必交换动态路由信息，占用设备的资源很少。就像我们作为游客跟团游的时候不必提前安排下一站的食宿，非常省心

因此静态路由更适用于小型、简单的网络，不适用于路由器较多、网络变化可能性高、较为复杂的网络


动态路由是与静态路由相对的一个概念，指路由器能够根据路由器之间交换的特定路由信息自动建立自己的路由表，并且能够根据链路和节点的变化适时地进行自动调整。

当网络节点或节点间的链路发生故障，或者存在其它可用路由时候，动态路由可以自行选择“最佳”的可用路由。
相似的，动态路由可以自动根据网络拓扑结构变化进行调整，同时也会占用路由器的CPU、内存和链路带宽。

距离向量法（Distance Vector Routing）和链路状态算法（Link-State Routing）。

RIP（Routing Information Protocol，路由信息协议）

OSPF（Open Shortest Path First，开放最短路径优先）

IS-IS（Intermediate System-to-Intermediate System，中间系统到中间系统）

BGP（Border Gateway Protocol，边界网关协议）

说说有哪些路由协议，都是如何更新的

参考回答

路由可分为静态&动态路由。静态路由由管理员手动维护；动态路由由路由协议自动维护。

路由选择算法的必要步骤：

1）向其它路由器传递路由信息；

2）接收其它路由器的路由信息；

3）根据收到的路由信息计算出到每个目的网络的最优路径，并由此生成路由选择表；

4）根据网络拓扑的变化及时的做出反应，调整路由生成新的路由选择表，同时把拓扑变化以路由信息的形式向其它路由器宣告。

两种主要算法：距离向量法（Distance Vector Routing）和链路状态算法（Link-State Routing）。

由此可分为距离矢量（如：RIP、IGRP、EIGRP）&链路状态路由协议（如：OSPF、IS-IS）。路由协议是路由器之间实现路由信息共享的一种机制，它允许路由器之间相互交换和维护各自的路由表。当一台路由器的路由表由于某种原因发生变化时，它需要及时地将这一变化通知与之相连接的其他路由器，以保证数据的正确传递。路由协议不承担网络上终端用户之间的数据传输任务。
1）RIP 路由协议(Routing Information Protocol)：RIP 协议最初是为 Xerox 网络系统的 Xerox parc 通用协议而设计的，是 Internet 中常用的路由协议。RIP 采用距离向量算法，即路由器根据距离选择路由，所以也称为距离向量协议。路由器收集所有可到达目的地的不同路径，并且保存有关到达每个目的地的最少站点数的路径信息，除到达目的地的最佳路径外，任何其它信息均予以丢弃。同时路由器也把所收集的路由信息用 RIP 协议通知相邻的其它路由器。这样，正确的路由信息逐渐扩散到了全网。RIP 使用非常广泛，它简单、可靠，便于配置。但是 RIP 只适用于小型的同构网络，因为它允许的最大站点数为 15，任何超过 15 个站点的目的地均被标记为不可达。而且 RIP 每隔 30s 一次的路由信息广播也是造成网络的广播风暴的重要原因之一。

2）OSPF 路由协议(Open Shortest Path First)：0SPF 是一种基于链路状态的路由协议，需要每个路由器向其同一管理域的所有其它路由器发送链路状态广播信息。在 OSPF 的链路状态广播中包括所有接口信息、所有的量度和其它一些变量。利用 0SPF 的路由器首先必须收集有关的链路状态信息，并根据一定的算法计算出到每个节点的最短路径。而基于距离向量的路由协议仅向其邻接路由器发送有关路由更新信息。与 RIP 不同，OSPF 将一个自治域再划分为区，相应地即有两种类型的路由选择方式： 当源和目的地在同一区时，采用区内路由选择；当源和目的地在不同区时，则采用区间路由选择。这就大大减少了网络开销，并增加了网络的稳定性。当一个区内的路由器出了故障时并不影响自治域内其它区路由器的正常工作，这也给网络的管理、维护带来方便。

3）BGP 和 BGP4 路由协议(Border Gateway Protocol)：BGP 是为 TCP／IP 互联网设计的外部网关协议，用于多个自治域之间。它既不是基于纯粹的链路状态算法，也不是基于纯粹的距离向量算法。它的主要功能是与其它自治域的 BGP 交换网络可达信息。各个自治域可以运行不同的内部网关协议。BGP 更新信息包括网络号／自治域路径的成对信息。自治域路径包括到达某个特定网络须经过的自治域串，这些更新信息通过 TCP 传送出去，以保证传输的可靠性。为了满足 Internet 日益扩大的需要，BGP 还在不断地发展。在最新的 BGP4 中，还可以将相似路由合并为一条路由。

4）IGRP 和 EIGRP 协议：EIGRP 和早期的 IGRP 协议都是由 Cisco 发明，是基于距离向量算法的动态路由协议。 EIGRP(Enhanced Interior Gateway Routing Protocol)是增强版的 IGRP 协议。它属于动态内部网关路由协议，仍然使用矢量－距离算法。但它的实现比 IGRP 已经有很大改进，其收敛特性和操作效率比 IGRP 有显著的提高。它的收敛特性是基于 DUAL ( Distributed Update Algorithm ) 算法的。DUAL 算法使得路径在路由计算中根本不可能形成环路。它的收敛时间可以与已存在的其他任何路由协议相匹敌

IS-IS（Intermediate System-to-Intermediate System，中间系统到中间系统）是一种链路状态协议，类似于 OSPF，但其路由选择算法略有不同，通常用于大规模网络

简述域名解析过程，本机如何干预域名解析

参考回答

（1）在浏览器中输入www.qq.com域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。

（2）如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。

（3）如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。

（4）如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。

（5）如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机。

（6）如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。
通过修改本机host来干预域名解析，例如：在/etc/hosts文件中添加一句话
192.168.188.1 www.baidu.com
保存文件后再ping一下www.baidu.com就会连接到192.168.188.1了

每一行为一条记录，分成两部分，第一部分是IP，第二部分是域名。
- 一个IP后面可以跟多个域名，可以是几十个甚至上百个
- 每一行只能有一个IP，也就是说一个域名不能对应多个IP
- 如果有多行中出现相同的域名（对应的ip不一样），会按最前面的记录来解析

DNS劫持就是通过劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现的。

简述网关的作用是什么，同一网段的主机如何通信

参考回答

网关即网络中的关卡，我们的互联网是一个一个的局域网、城域网、等连接起来的，在连接点上就是一个一个网络的关卡，即我们的网关，他是保证网络互连的，翻译和转换，使得不同的网络体系能够进行。
网内通信，即通信双方都位处同一网段中，数据传输无需经过路由器(或三层交换机)，即可由本网段自主完成。

假设发送主机的ARP表中并无目的主机对应的表项，则发送主机会以目的主机IP地址为内容，广播ARP请求以期获知目的主机MAC地址，并通过交换机(除到达端口之外的所有端口发送，即洪泛(Flooding))向全网段主机转发，而只有目的主机接收到此ARP请求后会将自己的MAC地址和IP地址装入ARP应答后将其回复给发送主机，发送主机接收到此ARP应答后，从中提取目的主机的MAC地址，并在其ARP表中建立目的主机的对应表项(IP地址到MAC地址的映射)，之后即可向目的主机发送数据，将待发送数据封装成帧，并通过二层设备(如交换机)转发至本网段内的目的主机，自此完成通信。

简述CSRF攻击的思想以及解决方法

参考回答

CSRF全称叫做，跨站请求伪造。就是黑客可以伪造用户的身份去做一些操作，进而满足自身目的。

要完成一次CSRF攻击，受害者必须依次完成两个步骤：

1）登录受信任网站A，并在本地生成Cookie。

2）在不登出A的情况下，访问危险网站B。

此时，黑客就可以获取你的cookie达成不可告人的目的了。
CSRF 攻击是一种请求伪造的攻击方式，它利用的是服务器不能识别用户的类型从而盗取用户的信息来攻击。因此要防御该种攻击，因为从服务器端着手，增强服务器的识别能力，设计良好的防御机制。主要有以下几种方式：

1）请求头中的Referer验证（不推荐）

HTTP的头部有一个Referer信息的字段，它记录着该次HTTP请求的来源地址（即它从哪里来的）,既然CSRF攻击是伪造请求是从服务器发送过来的，那么我们就禁止跨域访问，在服务器端增加验证，过滤掉那些不是从本服务器发出的请求，这样可以在一定程度上避免CSRF攻击。但是这也有缺点，比如如果是从搜索引擎所搜结果调整过来，请求也会被认为是跨域请求。

2）请求令牌验证（token验证）

token验证是一种比较广泛使用的防止CSRF攻击的手段，当用户通过正常渠道访问服务器时，服务器会生成一个随机的字符串保存在session中，并作为令牌（token）返回给客户端，以隐藏的形式保存在客户端中，客户端每次请求都会带着这个token，服务器根据该token判断该请求是否合法

说说 MAC地址和IP地址分别有什么作用

参考回答

IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。而MAC地址，指的是物理地址，用来定义网络设备的位置。
IP地址的分配是根据网络的拓扑结构，而不是根据谁制造了网络设置。若将高效的路由选择方案建立在设备制造商的基础上而不是网络所处的拓朴位置基础上，这种方案是不可行的。
当存在一个附加层的地址寻址时，设备更易于移动和维修。例如，如果一个以太网卡坏了，可以被更换，而无须取得一个新的IP地址。如果一个IP主机从一个网络移到另一个网络，可以给它一个新的IP地址，而无须换一个新的网卡。
无论是局域网，还是广域网中的计算机之间的通信，最终都表现为将数据包从某种形式的链路上的初始节点出发，从一个节点传递到另一个节点，最终传送到目的节点。数据包在这些节点之间的移动都是由ARP（Address Resolution Protocol：地址解析协议）负责将IP地址映射到MAC地址上来完成的。

MAC地址用于在网络中唯一标示一个网卡，一台设备若有一或多个网卡，则每个网卡都需要并会有一个唯一的MAC地址。MAC地址共48位（6个字节）。前24位由IEEE（电气和电子工程师协会）决定如何分配，后24位由实际生产该网络设备的厂商自行制定。例广播地址：FF:FF:FF:FF:FF:FF

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

三次握手

1）第一次握手：建立连接时，客户端向服务器发送SYN包（seq=x），请求建立连接，等待确认

2）第二次握手：服务端收到客户端的SYN包，回一个ACK包（ACK=x+1）确认收到，同时发送一个SYN包（seq=y）给客户端

3）第三次握手：客户端收到SYN+ACK包，再回一个ACK包（ACK=y+1）告诉服务端已经收到

4）三次握手完成，成功建立连接，开始传输数据

四次挥手

1）客户端发送FIN包（FIN=1)给服务端，告诉它自己的数据已经发送完毕，请求终止连接，此时客户端不发送数据，但还能接收数据

2）服务端收到FIN包，回一个ACK包给客户端告诉它已经收到包了，此时还没有断开socket连接，而是等待剩下的数据传输完毕

3）服务端等待数据传输完毕后，向客户端发送FIN包，表明可以断开连接

4）客户端收到后，回一个ACK包表明确认收到，等待一段时间，确保服务端不再有数据发过来，然后彻底断开连接

说说 TCP 2次握手行不行？为什么要3次

参考回答

为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认

tcp三次握手只要是为了确认线路的连通，第一次客户端发送到服务端，那么服务端就可以知道客户端的发送没有问题，但客户端不知道服务器的情况，第二次服务器发送ACK给客户端，客户端收到了证明服务端的收发都没有问题的，但服务端不知道客户端的接收情况，所以第三次是客户端再回给服务器一个ACK，服务器收到后就可以确保客户端的收发没有问题

简述 TCP 和 UDP 的区别，它们的头部结构是什么样的

参考回答

TCP协议是有连接的，有连接的意思是开始传输实际数据之前TCP的客户端和服务器端必须通过三次握手建立连接，会话结束之后也要结束连接。而UDP是无连接的

TCP协议保证数据按序发送，按序到达，提供超时重传来保证可靠性，但是UDP不保证按序到达，甚至不保证到达，只是努力交付，即便是按序发送的序列，也不保证按序送到。

TCP协议所需资源多，TCP首部需20个字节（不算可选项），UDP首部字段只需8个字节。

TCP有流量控制和拥塞控制，UDP没有，网络拥堵不会影响发送端的发送速率

TCP是一对一的连接，而UDP则可以支持一对一，多对多，一对多的通信。

TCP面向的是字节流的服务，UDP面向的是报文的服务。

HTTP 是基于 TCP 协议传输的，所以在这我们先了解下 TCP 协议。

TCP 包头格式

我们先看看 TCP 报文头部的格式：

TCP 包头格式

首先，源端口号和目标端口号是不可少的，如果没有这两个端口号，数据就不知道应该发给哪个应用。

接下来有包的序号，这个是为了解决包乱序的问题。

还有应该有的是确认号，目的是确认发出去对方是否有收到。如果没有收到就应该重新发送，直到送达，这个是为了解决丢包的问题。

接下来还有一些状态位。例如 SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等。TCP 是面向连接的，因而双方要维护连接的状态，这些带状态位的包的发送，会引起双方的状态变更。

还有一个重要的就是窗口大小。TCP 要做流量控制，通信双方各声明一个窗口（缓存大小），标识自己当前能够的处理能力，别发送的太快，撑死我，也别发的太慢，饿死我。

除了做流量控制以外，TCP还会做拥塞控制，对于真正的通路堵车不堵车，它无能为力，唯一能做的就是控制自己，也即控制发送的速度。不能改变世界，就改变自己嘛

/*TCP头定义，共20个字节*/ typedef struct _TCP_HEADER {  
short m_sSourPort;       // 源端口号16bit  
short m_sDestPort;       // 目的端口号16bit  
unsigned int m_uiSequNum;       // 序列号32bit  
unsigned int m_uiAcknowledgeNum;  // 确认号32bit  
short m_sHeaderLenAndFlag;     // 前4位：TCP头长度；中6位：保留；后6位：标志位 
short m_sWindowSize;       // 窗口大小16bit  
short m_sCheckSum;       // 检验和16bit 
short m_surgentPointer;     // 紧急数据偏移量16bit 
}__attribute__((packed))TCP_HEADER, *PTCP_HEADER;


而UDP报头只包含长度，源端口号，目的端口，和校验和。




基于TCP协议的：Telnet，FTP以及SMTP协议。

基于UDP协议的：DHCP、DNS、SNMP、TFTP、BOOTP。

netstat -napt

在 IP 协议里面需要有源地址 IP 和 目标地址 IP：

源地址IP，即是客户端输出的 IP 地址；
目标地址，即通过 DNS 域名解析得到的 Web 服务器 IP。

因为 HTTP 是经过 TCP 传输的，所以在 IP 包头的协议号，要填写为 06（十六进制），表示协议为 TCP。

至此，网络包的报文如下图。

IP 层报文

此时，加上了 IP 头部的数据包表示：“有 IP 大佬给我指路了，感谢 IP 层给我加上了 IP 包头，让我有了远程定位的能力！不会害怕在浩瀚的互联网迷茫了！可是目的地好远啊，我下一站应该去哪呢？”

生成了 IP 头部之后，接下来网络包还需要在 IP 头部的前面加上 MAC 头部。

MAC 包头格式

MAC 头部是以太网使用的头部，它包含了接收方和发送方的 MAC 地址等信息。

MAC 包头格式

在 MAC 包头里需要发送方 MAC 地址和接收方目标 MAC 地址，用于两点之间的传输。

一般在 TCP/IP 通信里，MAC 包头的协议类型只使用：

0800 ： IP 协议
0806 ： ARP 协议

此时就需要 ARP 协议帮我们找到路由器的 MAC 地址。

ARP 广播

ARP 协议会在以太网中以广播的形式，对以太网所有的设备喊出：“这个 IP 地址是谁的？请把你的 MAC 地址告诉我”。

然后就会有人回答：“这个 IP 地址是我的，我的 MAC 地址是 XXXX”。

如果对方和自己处于同一个子网中，那么通过上面的操作就可以得到对方的 MAC 地址。然后，我们将这个 MAC 地址写入 MAC 头部，MAC 头部就完成了。

好像每次都要广播获取，这不是很麻烦吗？

放心，在后续操作系统会把本次查询结果放到一块叫做 ARP 缓存的内存空间留着以后用，不过缓存的时间就几分钟。

也就是说，在发包时：

先查询 ARP 缓存，如果其中已经保存了对方的 MAC 地址，就不需要发送 ARP 查询，直接使用 ARP 缓存中的地址。
而当 ARP 缓存中不存在对方 MAC 地址时，则发送 ARP 广播查询。

查看 ARP 缓存内容

在 Linux 系统中，我们可以使用 arp -a 命令来查看 ARP 缓存的内容。

至此，网络包的报文如下图。

MAC 层报文

此时，加上了 MAC 头部的数据包万分感谢，说道：“感谢 MAC 大佬，我知道我下一步要去哪了！我现在有很多头部兄弟，相信我可以到达最终的目的地！”。带着众多头部兄弟的数据包，终于准备要出门了。

TCP 如何保证有序

参考回答

主机每次发送数据时，TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收主机对分配的这个序列号进行确认，如果发送主机在一个特定时间内没有收到接收主机的确认，则发送主机会重传此数据包。接收主机利用序列号对接收的数据进行确认，以便检测对方发送的数据是否有丢失或者乱序等，接收主机一旦收到已经顺序化的数据，它就将这些数据按正确的顺序重组成数据流并传递到高层进行处理。
具体步骤如下：

（1）为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区；

（2）并为每个已发送的数据包启动一个超时定时器；

（3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区;

（4）否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。

（5）接收方收到数据包后，先进行CRC校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到，如果接收方正好也有数据要发给发送方，应答包也可方在数据包中捎带过去。

TCP Tahoe/Reno

最初的实现，包括慢启动、拥塞避免两个部分。基于重传超时（retransmission timeout/RTO）和重复确认为条件判断是否发生了丢包。两者的区别在于：Tahoe算法下如果收到三次重复确认，就进入快重传立即重发丢失的数据包，同时将慢启动阈值设置为当前拥塞窗口的一半，将拥塞窗口设置为1MSS，进入慢启动状态；而Reno算法如果收到三次重复确认，就进入快重传，但不进入慢启动状态，而是直接将拥塞窗口减半，进入拥塞控制阶段，这称为“快恢复”。

而Tahoe和Reno算法在出现RTO时的措施一致，都是将拥塞窗口降为1个MSS，然后进入慢启动阶段。
TCP BBR（Bottleneck Bandwidth and Round-trip propagation time）

BBR是由Google设计，于2016年发布的拥塞算法。以往大部分拥塞算法是基于丢包来作为降低传输速率的信号，而BBR则基于模型主动探测。该算法使用网络最近出站数据分组当时的最大带宽和往返时间来建立网络的显式模型。数据包传输的每个累积或选择性确认用于生成记录在数据包传输过程和确认返回期间的时间内所传送数据量的采样率。该算法认为随着网络接口控制器逐渐进入千兆速度时，分组丢失不应该被认为是识别拥塞的主要决定因素，所以基于模型的拥塞控制算法能有更高的吞吐量和更低的延迟，可以用BBR来替代其他流行的拥塞算法，例如CUBIC。

控制时机提前，不再等到丢包时再进行暴力限制，而是控制稳定的发包速度，尽量榨干带宽，却又不让报文在中间设备的缓存队列上累积。

为了得到稳定的发包速度，BBR 使用 TCP Pacing 进行发包控制，因此 BBR 的实现也需要底层支持 TCP Pacing; 为了榨干带宽， BBR 会周期性地去探测是否链路条件变好了，如果是，则加大发送速率; 为了不让报文在中间设备的缓存队列上累积， BBR 会周期性地探测链路的最小 RTT，并使用该最小 RTT 计算发包速率。

简述 TCP 超时重传

参考回答

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

说说 TCP 可靠性保证

参考回答

TCP主要提供了检验和、序列号/确认应答、超时重传、最大消息长度、滑动窗口控制等方法实现了可靠性传输。

慢启动：在启动初期以指数增长方式增长；设置一个慢启动的阈值，当以指数增长达到阈值时就停止指数增长，按照线性增长方式增加至拥塞窗口；线性增长达到网络拥塞时立即把拥塞窗口置回1，进行新一轮的“慢启动”，同时新一轮的阈值变为原来的一半。

滑动窗口过小怎么办

我们可以假设窗口的大小是1，也是就每次只能发送一个数据，并且发送方只有接受方对这个数据进行确认了以后才能发送下一个数据。如果说窗口过小，那么当传输比较大的数据的时候需要不停的对数据进行确认，这个时候就会造成很大的延迟

述 TCP 的 TIME_WAIT，为什么需要有这个状态

参考回答

TIME_WAIT状态也成为2MSL等待状态。每个具体TCP实现必须选择一个报文段最大生存时间MSL（Maximum Segment Lifetime），它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的，因为TCP报文段以IP数据报在网络内传输，而IP数据报则有限制其生存时间的TTL字段。
主动发起关闭连接的一方，才会有 TIME-WAIT 状态

对一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2倍的MSL。这样可让TCP再次发送最后的ACK以防这个ACK丢失（另一端超时并重发最后的FIN）。

这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务器的IP地址和端口号）不能再被使用。这个连接只能在2MSL结束后才能再被使用。
理论上，四个报文都发送完毕，就可以直接进入CLOSE状态了，但是可能网络是不可靠的，有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
防止历史连接中的数据，被后面相同四元组的连接错误的接收；
保证「被动关闭连接」的一方，能被正确的关闭；
TIME-WAIT 作用是等待足够的时间以确保最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。

简述什么是 MSL，为什么客户端连接要等待2MSL的时间才能完全关闭

参考回答

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。
2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的

两个理由：
- 保证客户端发送的最后一个ACK报文段能够到达服务端。
  
  这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段，接着客户端重传一次确认，重新启动2MSL计时器，最后客户端和服务端都进入到CLOSED状态，若客户端在TIME-WAIT状态不等待一段时间，而是发送完ACK报文段后立即释放连接，则无法收到服务端重传的FIN+ACK报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到CLOSED状态。
- 防止“已失效的连接请求报文段”出现在本连接中。
  
  客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。

TIME_WAIT 过多有什么危害？

过多的 TIME-WAIT 状态主要的危害有两种：

第一是占用系统资源，比如文件描述符、内存资源、CPU 资源、线程资源等；
第二是占用端口资源，端口资源也是有限的，一般可以开启的端口为 32768～61000，也可以通过 net.ipv4.ip_local_port_range参数指定范围。

如果已经建立了连接，但是客户端突然出现故障了怎么办？
客户端出现故障指的是客户端的主机发生了宕机，或者断电的场景。发生这种情况的时候，如果服务端一直不会发送数据给客户端，那么服务端是永远无法感知到客户端宕机这个事件的，也就是服务端的 TCP 连接将一直处于 ESTABLISH 状态，占用着系统资源。

为了避免这种情况，TCP 搞了个保活机制。这个机制的原理是这样的：

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序

说说什么是 SYN flood，如何防止这类攻击？

参考回答

广播是向同一子网内所有的端口（包括自己的那个端口）发送消息; 泛洪只是在所有的端口中不包括发送消息的（自己的）那个端口发送消息.

关于泛洪，这也是一种交换机常用的转发方式，当交换机要给一个目的主机发送数据帧，而数据帧中的目的MAC地址不在交换机MAC地址表中，则向除了接收端口以外的所有其他端口转发。这个动作就是泛洪

SYN Flood是当前最流行的DoS（拒绝服务攻击）与DDoS(分布式拒绝服务攻击)的方式之一，这是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，使被攻击方资源耗尽（CPU满负荷或内存不足)的攻击方式.
有以下三种方法预防或响应网络上的DDoS攻击：

(1)从互联网服务提供商(ISP)购买服务。

许多互联网服务提供商(ISP)提供DDoS缓解服务，但是当企业网络受到攻击时，企业需要向互联网服务提供商(ISP)报告事件以开始缓解。这种策略称为“清洁管道”，在互联网服务提供商(ISP)收取服务费用时很受欢迎，但在缓解措施开始之前，通常会导致30到60分钟的网络延迟。

(2)保留在内部并自己解决。

企业可以使用入侵防御系统/防火墙技术和专用于防御DDoS攻击的专用硬件来实现内部预防和响应DDoS攻击。不幸的是，受影响的流量已经在网络上消耗了宝贵的带宽。这使得该方法最适合在托管设施中配备设备的企业，在这些企业中，流量是通过交叉连接到达互联网服务提供商(ISP)，从而保护流向企业其他部门的下游带宽。

(3)使用内容分发网络(CDN)。

由于IT团队可以将基础设施置于内容分发网络(CDN)后面，因此这种方法可以最大程度地减少对企业网络基础设施的攻击。这些网络庞大而多样，如果组织订阅DNS和DDoS缓解措施，则它们可以保护电子商务站点以及企业本身。

说说什么是 TCP 粘包和拆包？

参考回答

TCP是个“流”协议，所谓流，就是没有界限的一串数据。大家可以想想河里的流水，是连成一片的，其间并没有分界线。TCP底层并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行包的划分，所以在业务上认为，一个完整的包可能会被TCP拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的TCP粘包和拆包问题。

答案解析

假设客户端分别发送了两个数据包D1和D2给服务端，由于服务端一次读取到的字节数是不确定的，故可能存在以下4种情况。

（1）服务端分两次读取到了两个独立的数据包，分别是D1和D2，没有粘包和拆包；

（2）服务端一次接收到了两个数据包，D1和D2粘合在一起，被称为TCP粘包；

（3）服务端分两次读取到了两个数据包，第一次读取到了完整的D1包和D2包的部分内容，第二次读取到了D2包的剩余内容，这被称为TCP拆包；

（4）服务端分两次读取到了两个数据包，第一次读取到了D1包的部分内容D1_1，第二次读取到了D1包的剩余内容D1_2和D2包的整包。

如果此时服务端TCP接收滑窗非常小，而数据包D1和D2比较大，很有可能会发生第五种可能，即服务端分多次才能将D1和D2包接收完全，期间发生多次拆包。

说一说 TCP 的 keepalive，以及和 HTTP 的 keepalive 的区别？

参考回答

HTTP Keep-Alive

在http早期，每个http请求都要求打开一个tpc socket连接，并且使用一次之后就断开这个tcp连接。使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。但是，keep-alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。
TCP KEEPALIVE

链接建立之后，如果应用程序或者上层协议一直不发送数据，或者隔很长时间才发送一次数据，当链接很久没有数据报文传输时如何去确定对方还在线，到底是掉线了还是确实没有数据传输，链接还需不需要保持，这种情况在TCP协议设计中是需要考虑到的。TCP协议通过一种巧妙的方式去解决这个问题，当超过一段时间之后，TCP自动发送一个数据为空的报文给对方，如果对方回应了这个报文，说明对方还在线，链接可以继续保持，如果对方没有报文返回，并且重试了多次之后则认为链接丢失，没有必要保持链接。
TCP的keepalive机制和HTTP的keep-alive机制是说的完全不同的两个东西，tcp的keepalive是在ESTABLISH状态的时候，双方如何检测连接的可用行。而http的keep-alive说的是如何避免进行重复的TCP三次握手和四次挥手的环节。

说说 TCP 如何加速一个大文件的传输

参考回答

建连优化：TCP 在建立连接时，如果丢包，会进入重试，重试时间是 1s、2s、4s、8s 的指数递增间隔，缩短定时器可以让 TCP 在丢包环境建连时间更快，非常适用于高并发短连接的业务场景。
平滑发包：在 RTT 内均匀发包，规避微分时间内的流量突发，尽量避免瞬间拥塞
丢包预判：有些网络的丢包是有规律性的，例如每隔一段时间出现一次丢包，例如每次丢包都连续丢几个等，如果程序能自动发现这个规律（有些不明显），就可以针对性提前多发数据，减少重传时间、提高有效发包率。
RTO 探测：若始终收不到 ACK 报文，则需要触发 RTO 定时器。RTO 定时器一般都时间非常长，会浪费很多等待时间，而且一旦 RTO，CWND 就会骤降（标准 TCP），因此利用 Probe 提前与 RTO 去试探，可以规避由于 ACK 报文丢失而导致的速度下降问题。
带宽评估：通过单位时间内收到的 ACK 或 SACK 信息可以得知客户端有效接收速率，通过这个速率可以更合理的控制发包速度。
带宽争抢：有些场景（例如合租）是大家互相挤占带宽的，假如你和室友各 1Mbps 的速度看电影，会把 2Mbps 出口占满，而如果一共有 3 个人看，则每人只能分到 1/3。若此时你的流量流量达到 2Mbps，而他俩还都是 1Mbps，则你至少仍可以分到 2/(2+1+1) * 2Mbps = 1Mbps 的 50% 的带宽，甚至更多，代价就是服务器侧的出口流量加大，增加成本。（TCP 优化的本质就是用带宽换用户体验感）

说说浏览器从输入 URL 到展现页面的全过程

参考回答

1、输入地址
2、浏览器查找域名的 IP 地址
3、浏览器向 web 服务器发送一个 HTTP 请求
4、服务器的永久重定向响应
6、服务器处理请求
7、服务器返回一个 HTTP 响应
8、浏览器显示 HTML
9、浏览器发送请求获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS等等）

简述 HTTP 和 HTTPS 的区别？

参考回答

HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

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

https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
两者的默认端口不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的

说说 HTTP 中的 referer 头的作用

参考回答

HTTP Referer是header的一部分，当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器该网页是从哪个页面链接过来的，服务器因此可以获得一些信息用于处理。
防盗链。假如在www.google.com里有一个[www.baidu.com](https://www.nowcoder.com/issue/www.baidu.com)链接，那么点击进入这个[www.baidu.com](https://www.nowcoder.com/issue/www.baidu.com)，它的header信息里就有：Referer= http://www.google.com

只允许我本身的网站访问本身的图片服务器，假如域是www.google.com，那么图片服务器每次取到Referer来判断一下域名是不是www.google.com，如果是就继续访问，不是就拦截。

将这个http请求发给服务器后，如果服务器要求必须是某个地址或者某几个地址才能访问，而你发送的referer不符合他的要求，就会拦截或者跳转到他要求的地址，然后再通过这个地址进行访问。
防止恶意请求

比如静态请求是*.html结尾的，动态请求是*.shtml，那么由此可以这么用，所有的*.shtml请求，必须Referer为我自己的网站。
空Referer

定义：Referer头部的内容为空，或者，一个HTTP请求中根本不包含Referer头部（一个请求并不是由链接触发产生的）

直接在浏览器的地址栏中输入一个资源的URL地址，那么这种请求是不会包含Referer字段的，因为这是一个“凭空产生”的HTTP请求，并不是从一个地方链接过去的。

那么在防盗链设置中，允许空Referer和不允许空Referer有什么区别？

允许Referer为空，意味着你允许比如浏览器直接访问。
防御CSRF

比对HTTP 请求的来源地址，如果Referer中的地址是安全可信任的地址，那么就放行

3.35 说说 HTTP 的方法有哪些

参考回答

GET：用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT：传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD：获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URI支持的HTTP方法。

3.36 简述 HTTP 1.0，1.1，2.0 ，3.0 的主要区别

参考回答

http/1.0 :

默认不支持长连接，需要设置keep-alive参数指定
强缓存expired、协商缓存last-modified\if-modified-since 有一定的缺陷

http 1.1 :

默认长连接(keep-alive)，http请求可以复用Tcp连接，但是同一时间只能对应一个http请求(http请求在一个Tcp中是串行的)
增加了强缓存cache-control、协商缓存etag\if-none-match 是对http/1 缓存的优化

http/2.0 :

多路复用，一个Tcp中多个http请求是并行的 (雪碧图、多域名散列等优化手段http/2中将变得多余)
通过 Stream 这个设计，多个 Stream 复用一条 TCP 连接，达到并发的效果，解决了 HTTP/1.1 队头阻塞的问题，提高了 HTTP 传输的吞吐量
二进制格式编码传输
服务器主动推送资源
HTTP/2 没使用常见的 gzip 压缩方式来压缩头部，而是开发了 HPACK 算法
总结

HTTP/2 协议其实还有很多内容，比如流控制、流状态、依赖关系等等。

这次主要介绍了关于 HTTP/2 是如何提升性能的几个方向，它相比 HTTP/1 大大提高了传输效率、吞吐能力。

第一点，对于常见的 HTTP 头部通过静态表和 Huffman 编码的方式，将体积压缩了近一半，而且针对后续的请求头部，还可以建立动态表，将体积压缩近 90%，大大提高了编码效率，同时节约了带宽资源。

不过，动态表并非可以无限增大，因为动态表是会占用内存的，动态表越大，内存也越大，容易影响服务器总体的并发能力，因此服务器需要限制 HTTP/2 连接时长或者请求次数。

第二点，HTTP/2 实现了 Stream 并发，多个 Stream 只需复用 1 个 TCP 连接，节约了 TCP 和 TLS 握手时间，以及减少了 TCP 慢启动阶段对流量的影响。不同的 Stream ID 可以并发，即使乱序发送帧也没问题，比如发送 A 请求帧 1 -> B 请求帧 1 -> A 请求帧 2 -> B 请求帧2，但是同一个 Stream 里的帧必须严格有序。

另外，可以根据资源的渲染顺序来设置 Stream 的优先级，从而提高用户体验。

第三点，服务器支持主动推送资源，大大提升了消息的传输性能，服务器推送资源时，会先发送 PUSH_PROMISE 帧，告诉客户端接下来在哪个 Stream 发送资源，然后用偶数号 Stream 发送资源给客户端。

HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。

HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。

有没有什么解决方案呢？既然是 TCP 协议自身的问题，那干脆放弃 TCP 协议，转而使用 UDP 协议作为传输层协议，这个大胆的决定，HTTP/3 协议做了！

美中不足的 HTTP/2

队头阻塞；
TCP 与 TLS 的握手时延迟；
网络迁移需要重新连接；

HTTP/3 不仅仅只是简单将传输协议替换成了 UDP，还基于 UDP 协议在「应用层」实现了 QUIC 协议，它具有类似 TCP 的连接管理、拥塞窗口、流量控制的网络特性，相当于将不可靠传输的 UDP 协议变成“可靠”的了，所以不用担心数据包丢失的问题。

QUIC 协议的优点有很多，这里举例几个，比如：

无队头阻塞；
更快的连接建立；
连接迁移

Host 字段

客户端发送请求时，用来指定服务器的域名

Content-Length 字段

服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度，HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题

Connection 字段

Connection 字段最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用。HTTP 长连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。HTTP/1.1 版本的默认连接都是长连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive

Content-Type 字段

Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。

Content-Encoding 字段

Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式

强制缓存和协商缓存

HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存

强缓存指的是只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

如下图中，返回的是 200 状态码，但在 size 项中标识的是 from disk cache，就是使用了强制缓存，Cache-Control 的优先级高于 Expires 。

协商缓存：当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

****协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存

协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求

下图是强制缓存和协商缓存的工作流程：

当使用 ETag 字段实现的协商缓存的过程：

当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 ETag 唯一标识，这个唯一标识的值是根据当前请求的资源生成的；
当浏览器再次请求访问服务器中的该资源时，首先会先检查强制缓存是否过期：
- 如果没有过期，则直接使用本地缓存；
- 如果缓存过期了，会在 Request 头部加上 If-None-Match 字段，该字段的值就是 ETag 唯一标识；
服务器再次收到请求后，

会根据请求中的 If-None-Match 值与当前请求的资源生成的唯一标识进行比较

：
- 如果值相等，则返回 304 Not Modified，不会返回资源；
- 如果不相等，则返回 200 状态码和返回资源，并在 Response 头部加上新的 ETag 唯一标识；
如果浏览器收到 304 的请求响应状态码，则会从本地缓存中加载资源，否则更新资源。

3.37 说说 HTTP 常见的响应状态码及其含义

参考回答

200 : 从状态码发出的请求被服务器正常处理。
204 : 服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分【即没有内容】。
206 : 部分的内容（如：客户端进行了范围请求，但是服务器成功执行了这部分的干请求）。
301 : 跳转，代表永久性重定向（请求的资源已被分配了新的URI，以后已使用资源，现在设置了URI）。
302 : 临时性重定向（请求的资源已经分配了新的URI，希望用户本次能够使用新的URI来进行访问）。
303 : 由于请求对应的资源存在的另一个URI（因使用get方法，定向获取请求的资源）。
304 : 客户端发送附带条件的请求时，服务器端允许请求访问资源，但因发生请求未满足条件的情况后，直接返回了 304。
307 : 临时重定向【该状态码与302有着相同的含义】。
400 : 请求报文中存在语法错误（当错误方式时，需修改请求的内容后，再次发送请求）。
401 : 发送的请求需要有通过HTTP认证的认证信息。
403 : 对请求资源的访问被服务器拒绝了。
404 : 服务器上无法找到请求的资源。
500 : 服务器端在执行请求时发生了错误。
503 : 服务器暂时处于超负载或者是正在进行停机维护，现在无法处理请求。

答案解析

1XX : 信息类状态码（表示接收请求状态处理）
2XX : 成功状态码（表示请求正常处理完毕）
3XX : 重定向（表示需要进行附加操作，已完成请求）
4XX : 客户端错误（表示服务器无法处理请求）
5XX : 服务器错误状态码（表示服务器处理请求的时候出错）

3.38 说说 GET请求和 POST 请求的区别

参考回答

GET请求在URL中传送的参数是有长度限制的，而POST没有。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET在浏览器回退时是无害的，而POST会再次提交请求。

Cookie与Session都是会话的一种方式。它们的典型使用场景比如“购物车”，当你点击下单按钮时，服务端并不清楚具体用户的具体操作，为了标识并跟踪该用户，了解购物车中有几样物品，服务端通过为该用户创建Cookie/Session来获取这些信息。
cookie数据存放在客户的浏览器上，session数据放在服务器上。
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗考虑到安全应当使用session。
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用COOKIE。
单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

3.40 简述 HTTPS 的加密与认证过程

参考回答

客户端在浏览器中输入一个https网址，然后连接到server的443端口采用https协议的server必须有一套数字证书（一套公钥和密钥）首先server将证书（公钥）传送到客户端客户端解析证书，验证成功，则生成一个随机数（私钥），并用证书将该随机数加密后传回server server用密钥解密后，获得这个随机值，然后将要传输的信息和私钥通过某种算法混合在一起（加密）传到客户端客户端用之前的生成的随机数（私钥）解密服务器端传来的信息
首先浏览器会从内置的证书列表中索引，找到服务器下发证书对应的机构，如果没有找到，此时就会提示用户该证书是不是由权威机构颁发，是不可信任的。如果查到了对应的机构，则取出该机构颁发的公钥。

用机构的证书公钥解密得到证书的内容和证书签名，内容包括网站的网址、网站的公钥、证书的有效期等。浏览器会先验证证书签名的合法性。签名通过后，浏览器验证证书记录的网址是否和当前网址是一致的，不一致会提示用户。如果网址一致会检查证书有效期，证书过期了也会提示用户。这些都通过认证时，浏览器就可以安全使用证书中的网站公钥了。

HTTP/1.1 如何优化

尽量避免发送 HTTP 请求；
在需要发送 HTTP 请求时，考虑如何减少请求次数；
减少服务器的 HTTP 响应的数据大小

尽量避免发送 HTTP 请求；

聪明的你可能想到了，万一缓存的响应不是最新的，而客户端并不知情，那么该怎么办呢？

放心，这个问题 HTTP 设计者早已考虑到。

所以，服务器在发送 HTTP 响应时，会估算一个过期的时间，并把这个信息放到响应头部中，这样客户端在查看响应头部的信息时，一旦发现缓存的响应是过期的，则就会重新发送网络请求。

减少重定向请求次数

重定向的工作交由代理服务器完成，就能减少 HTTP 请求次数了

合并请求

一般浏览器会同时发起 5-6 个请求，每一个请求都是不同的 TCP 连接，那么如果合并了请求，也就会减少 TCP 连接的数量，因而省去了 TCP 握手和慢启动过程耗费的时间。

有的网页会含有很多小图片、小图标，有多少个小图片，客户端就要发起多少次请求。那么对于这些小图片，我们可以考虑使用 CSS Image Sprites 技术把它们合成一个大图片，这样浏览器就可以用一次请求获得一个大图片，然后再根据 CSS 数据把大图片切割成多张小图片，webpack 等打包工具将 js、css 等资源合并打包成大文件，也是能达到类似的效果

延迟发送请求

不要一口气吃成大胖子，一般 HTML 里会含有很多 HTTP 的 URL，当前不需要的资源，我们没必要也获取过来，于是可以通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数

减少HTTP 响应的数据

压缩的方式一般分为 2 种，分别是：

无损压缩；
有损压缩；

总结

第一个思路是，通过缓存技术来避免发送 HTTP 请求。客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。

第二个思路是，减少 HTTP 请求的次数，有以下的方法：

将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；
将多个小资源合并成一个大资源再传输，能够减少 HTTP 请求次数以及头部的重复传输，再来减少 TCP 连接数量，进而省去 TCP 握手和慢启动的网络消耗；
按需访问资源，只访问当前用户看得到/用得到的资源，当客户往下滑动，再访问接下来的资源，以此达到延迟请求，也就减少了同一时间的 HTTP 请求次数。

第三思路是，通过压缩响应资源，降低传输资源的大小，从而提高传输效率，所以应当选择更优秀的压缩算法。

HTTPS RSA 握手解析

https://cdn.xiaolincoding.com/gh/xiaolincoder/ImageHost4@main/%E7%BD%91%E7%BB%9C/https/https_rsa.png

HTTPS 如何优化

硬件优化

HTTPS 协议是计算密集型，而不是 I/O 密集型

软件优化

将 Linux 内核从 2.x 升级到 4.x；
将 OpenSSL 从 1.0.1 升级到 1.1.1；

协议优化

RSA 密钥交换算法的 TLS 握手过程，不仅慢，而且安全性也不高。

因此如果可以，尽量选用 ECDHE 密钥交换算法替换 RSA 算法，因为该算法由于支持「False Start」，它是“抢跑”的意思，客户端可以在 TLS 协议的第 3 次握手后，第 4 次握手前，发送加密的应用数据，以此将 TLS 握手的消息往返由 2 RTT 减少到 1 RTT，而且安全性也高，具备前向安全性。

TLS 升级

总结

对于硬件优化的方向，因为 HTTPS 是属于计算密集型，应该选择计算力更强的 CPU，而且最好选择支持 AES-NI 特性的 CPU，这个特性可以在硬件级别优化 AES 对称加密算法，加快应用数据的加解密。

对于软件优化的方向，如果可以，把软件升级成较新的版本，比如将 Linux 内核 2.X 升级成 4.X，将 openssl 1.0.1 升级到 1.1.1，因为新版本的软件不仅会提供新的特性，而且还会修复老版本的问题。

对于协议优化的方向：

密钥交换算法应该选择 ECDHE 算法，而不用 RSA 算法，因为 ECDHE 算法具备前向安全性，而且客户端可以在第三次握手之后，就发送加密应用数据，节省了 1 RTT。
将 TLS1.2 升级 TLS1.3，因为 TLS1.3 的握手过程只需要 1 RTT，而且安全性更强。

对于证书优化的方向：

服务器应该选用 ECDSA 证书，而非 RSA 证书，因为在相同安全级别下，ECC 的密钥长度比 RSA 短很多，这样可以提高证书传输的效率；
服务器应该开启 OCSP Stapling 功能，由服务器预先获得 OCSP 的响应，并把响应结果缓存起来，这样 TLS 握手的时候就不用再访问 CA 服务器，减少了网络通信的开销，提高了证书验证的效率；

对于重连 HTTPS 时，我们可以使用一些技术让客户端和服务端使用上一次 HTTPS 连接使用的会话密钥，直接恢复会话，而不用再重新走完整的 TLS 握手过程。

常见的会话重用技术有 Session ID 和 Session Ticket，用了会话重用技术，当再次重连 HTTPS 时，只需要 1 RTT 就可以恢复会话。对于 TLS1.3 使用 Pre-shared Key 会话重用技术，只需要 0 RTT 就可以恢复会话。

这些会话重用技术虽然好用，但是存在一定的安全风险，它们不仅不具备前向安全，而且有重放攻击的风险，所以应当对会话密钥设定一个合理的过期时间。

既然有 HTTP 协议，为什么还要有 RPC

RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。

而 RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。

纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义消息边界。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。
RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。
从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。
RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP/1.1 性能要更好，所以大部分公司内部都还在使用 RPC。
HTTP/2.0 在 HTTP/1.1 的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。

既然有 HTTP 协议，为什么还要有 WebSocket？

WebSocket : 需要服务器和客户端（浏览器）频繁交互的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件

使用 HTTP 不断轮询

其实问题的痛点在于，怎么样才能在用户不做任何操作的情况下，网页能收到消息并发生变更。

最常见的解决方案是，网页的前端代码里不断定时发 HTTP 请求到服务器，服务器收到请求后给客户端响应消息。

这其实时一种「伪」服务器推的形式。

它其实并不是服务器主动发消息到客户端，而是客户端自己不断偷偷请求服务器，只是用户无感知而已

长轮询

我们知道，HTTP 请求发出后，一般会给服务器留一定的时间做响应，比如 3 秒，规定时间内没返回，就认为是超时。

如果我们的 HTTP 请求将超时设置的很大，比如 30 秒，在这 30 秒内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。

这样就减少了 HTTP 请求的个数，并且由于大部分情况下，用户都会在某个 30 秒的区间内做扫码操作，所以响应也是及时的

我们知道 TCP 连接的两端，同一时间里，双方都可以主动向对方发送数据。这就是所谓的全双工。

而现在使用最广泛的HTTP/1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。

也就是说，好好的全双工 TCP，被 HTTP/1.1 用成了半双工。

为什么？

这是由于 HTTP 协议设计之初，考虑的是看看网页文本的场景，能做到客户端发起请求再由服务器响应，就够了，根本就没考虑网页游戏这种，客户端和服务器之间都要互相主动发大量数据的场景。

所以，为了更好的支持这样的场景，我们需要另外一个基于TCP的新协议。

于是新的应用层协议WebSocket就被设计出来了。

大家别被这个名字给带偏了。虽然名字带了个socket，但其实 socket 和 WebSocket 之间，就跟雷峰和雷峰塔一样，二者接近毫无关系。

Connection: Upgrade
Upgrade: WebSocket
Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n

这些 header 头的意思是，浏览器想升级协议（Connection: Upgrade），并且想升级成 WebSocket 协议（Upgrade: WebSocket）。同时带上一段随机生成的 base64 码（Sec-WebSocket-Key），发给服务器。

总结

TCP 协议本身是全双工的，但我们最常用的 HTTP/1.1，虽然是基于 TCP 的协议，但它是半双工的，对于大部分需要服务器主动推送数据到客户端的场景，都不太友好，因此我们需要使用支持全双工的 WebSocket 协议。
在 HTTP/1.1 里，只要客户端不问，服务端就不答。基于这样的特点，对于登录页面这样的简单场景，可以使用定时轮询或者长轮询的方式实现服务器推送(comet)的效果。
对于客户端和服务端之间需要频繁交互的复杂场景，比如网页游戏，都可以考虑使用 WebSocket 协议。
WebSocket 和 socket 几乎没有任何关系，只是叫法相似。
正因为各个浏览器都支持 HTTP协议，所以 WebSocket 会先利用HTTP协议加上一些特殊的 header 头进行握手升级操作，升级成功后就跟 HTTP 没有任何关系了，之后就用 WebSocket 的数据格式进行收发数据。

IP地址

IP地址还分为私网地址和公网地址，其中私网地址只能在局域网内部使用，不能访问Internet。

私有IP地址：

①　A类：10.0.0.0-10.255.255.255

②　B类：172.16.0.0-172.31.255.255

③　C类：192.168.0.0-192.168.255.255

A 类地址 8bit 网络号 + 24bit 主机号

B 类地址 16bit 网络号 + 16bit 主机号

C 类地址 24bit 网络号 + 8bit 主机号

D 类地址多播地址

E 类地址保留

特殊地址：

本地环回地址：127.0.0.1（测试本机的网络配置，能ping通127.0.0.1说明本机的网卡和IP协议安装都没有问题）

本地广播地址：255.255.255.255 广播地址主机号全1

IP地址 & 子网掩码 = 网络地址

网络地址 || （~子网掩码）=广播地址

邮件

用户*** –http–> 邮件服务器 —–smtp —> 邮件服务器 —http —> 用户***

IEEE 802系列标准是IEEE 802 LAN/MAN 标准***会制定的局域网、城域网技术标准。其中最广泛使用的有以太网、令牌环、无线局域网等

我国要求局用程控交换机的系统中断时间为平均每年不超过3分钟

IEEE 802.1 ：局域网体系结构、寻址、网络互联和网络。

IEEE 802.1A：概述和系统结构。

IEEE 802.1B：网络管理和网络互连。

IEEE 802.2 ：逻辑链路控制子层（LLC）的定义。

IEEE 802.3 ：以太网介质访问控制协议（CSMA/CD）及物理层技术规范。

IEEE 802.4 ：令牌总线网（Token-Bus）的介质访问控制协议及物理层技术规范。

IEEE 802.5 ：令牌环网（Token-Ring)的介质访问控制协议及物理层技术规范。

IEEE 802.6 ：城域网介质访问控制协议DQDB （Distributed Queue Dual Bus 分布式队列双总线）及物理层技术规范。

IEEE 802.7 ：宽带技术咨询组，提供有关宽带联网的技术咨询。

IEEE 802.8 ：光纤技术咨询组，提供有关光纤联网的技术咨询。

IEEE 802.9 ：综合声音数据的局域网（IVD LAN）介质访问控制协议及物理层技术规范。

IEEE 802.10：网络安全技术咨询组，定义了网络互操作的认证和加密方法。

IEEE 802.11：无线局域网（WLAN）的介质访问控制协议及物理层技术规范

名字转换 DNS UDP 文件传送 TFTP UDP 路由选择协议 RIP UDP IP地址配置 DHCP UDP 网络管理 SNMP UDP 远程文件服务器 NFS UDP IP电话专用协议 UDP 流式多媒体通信专用协议 UDP 多播 IGMP UDP 电子邮件 SMTP TCP 远程终端接入 TELNET TCP 万维网 HTTP TCP 文件传送 FTP TCP

互联网计算机在相互通信时必须遵循统一的规则称为网络协议

计算机网络

请说一下socket网络编程中客户端和服务端用到哪些函数？

TCP 半连接队列和全连接队列

没有 accept，能建立 TCP 连接吗？

没有 listen，能建立 TCP 连接吗？

如何优化 TCP?

TCP 三次握手的性能提升；

TCP 四次挥手的性能提升；

TCP 数据传输的性能提升

如何基于 UDP 协议实现可靠传输？

2.61 简述网络七层参考模型，每一层的作用？

简述静态路由和动态路由

说说有哪些路由协议，都是如何更新的

简述域名解析过程，本机如何干预域名解析

简述网关的作用是什么，同一网段的主机如何通信

简述CSRF攻击的思想以及解决方法

说说 MAC地址和IP地址分别有什么作用

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

三次握手

四次挥手

说说 TCP 2次握手行不行？为什么要3次

简述 TCP 和 UDP 的区别，它们的头部结构是什么样的

TCP 如何保证有序

简述 TCP 超时重传

说说 TCP 可靠性保证

滑动窗口过小怎么办

述 TCP 的 TIME_WAIT，为什么需要有这个状态

简述什么是 MSL，为什么客户端连接要等待2MSL的时间才能完全关闭

TIME_WAIT 过多有什么危害？

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

说说什么是 SYN flood，如何防止这类攻击？

说说什么是 TCP 粘包和拆包？

说一说 TCP 的 keepalive，以及和 HTTP 的 keepalive 的区别？

说说 TCP 如何加速一个大文件的传输

说说浏览器从输入 URL 到展现页面的全过程

简述 HTTP 和 HTTPS 的区别？

说说 HTTP 中的 referer 头的作用

3.35 说说 HTTP 的方法有哪些

3.36 简述 HTTP 1.0，1.1，2.0 ，3.0 的主要区别

美中不足的 HTTP/2

强制缓存和协商缓存

3.37 说说 HTTP 常见的响应状态码及其含义

3.38 说说 GET请求和 POST 请求的区别

3.39 说说 Cookie 和 Session 的关系和区别是什么

3.40 简述 HTTPS 的加密与认证过程

HTTP/1.1 如何优化

尽量避免发送 HTTP 请求；

减少重定向请求次数

合并请求

延迟发送请求

减少HTTP 响应的数据

总结

HTTPS RSA 握手解析

HTTPS 如何优化

总结

既然有 HTTP 协议，为什么还要有 RPC

既然有 HTTP 协议，为什么还要有 WebSocket？

使用 HTTP 不断轮询

长轮询

总结

IP地址