计算机网络校招高频面试题整理（含答案）

一 Http相关
1 Http概念：

超文本传输协议:H即超文本，可以传输除了文本以外的视频，图片，甚至链接。

2 Http常见的状态码有哪些:

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。
2xx 类状态码表示服务器成功处理了客户端的请求
3xx
类状态码表示客户端请求的资源发送了变动，需要重新发送请求，也就是重定向。
4xx 类状态码表示客户端发送的报文有误，服务器无法处理
5xx 类状态码表示 客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

3 Http头部(我的爬虫项目里用了，需要用）
Http头部总结
4 get和post方法的区别:

1 从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
2 从编码的角度，GET 只能进行 URL编码，只能接收 ASCII 字符，而 POST 没有限制。
3 从参数的角度，GET 一般放在 URL 中，因此不安全，长度有限，POST放在请求体中，更适合传输敏感信息。
4 从幂等性的角度，GET是幂等的，而POST不是。(幂等表示执行多次相同的操作，结果也是相同的)
5 从TCP的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，首先发 header 部分，如果服务器响应 100(continue)， 然后发 body 部分。(火狐浏览器除外，它的 POST 请求只发一个 TCP 包)

5 Http1.0,1.1,2.0
三者特性对比
细节补充

6 HTTP 是不保存状态的协议、那么如何保存用户状态。

Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。
典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP
协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个
用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session

7 Cookie 的作用是什么、和 Session 有什么区别

Cookie 存储在客户端： cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

session 认证流程：
用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作

区别：

1 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
2 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
3 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源

8 Session 的实现机制是什么

session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。

当程序需要为某个客户端的请求创建一个session的时候，服务器首先检查这个客户端的请求里是否已包含了一个session标识 -称为session id，
如果已包含一个session id则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（如果检索不到，可能会新建一个）
，如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的session id，sessiond的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。
保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。
由于cookie可以被人为的禁止，必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。

9 分布式Session会有什么问题？怎么解决

问题：用户在第一次访问网站时，Nginx通过其负载均衡机制将用户请求转发到A服务器，这时A服务器就会给用户创建一个Session。当用户第二次发送请求时，Nginx将其负载均衡到B服务器，而这时候B服务器并不存在Session，所以就会将用户踢到登录页面。这将大大降低用户体验度，导致用户的流失，这种情况是项目绝不应该出现的。

1. 存入 Cookie 中

可以将 Session 存储到 Cookie 中，但是缺点也很明显，例如每次请求都得带着 Session
，数据存储在客户端本地，是有风险的；

2. Session 同步

原理：任何一个服务器上的session发生改变（增删改），该节点会把这个
session的所有内容序列化，然后广播给所有其它节点，不管其他服务器需不需要session，以此来保证Session同步。

优点：可容错，各个服务器间session能够实时响应。

缺点：会对网络负荷造成一定压力，如果session量大的话可能会造成网络堵塞，拖慢服务器性能。

实现方式：

设置tomcat ，server.xml 开启tomcat集群功能

3. IP绑定

原理：粘性Session是指将用户锁定到某一个服务器上，比如上面说的例子，用户第一次请求时，负载均衡器将用户的请求转发到了A服务器上，如果负载均衡器设置了粘性Session的话，那么用户以后的每次请求都会转发到A服务器上，相当于把用户和A服务器粘到了一块，这就是粘性Session机制。

优点：简单，不需要对session做任何处理。

缺点：缺乏容错性，如果当前访问的服务器发生故障，用户被转移到第二个服务器上时，他的session信息都将失效。

适用场景：发生故障对客户产生的影响较小；服务器发生故障是低概率事件。

4. 持久化到数据库

实现了 Session 共享； 可以水平扩展（增加 Redis 服务器）； 服务器重启 Session 不丢失（不过也要注意 Session
在 Redis 中的刷新/失效机制）； 不仅可以跨服务器 Session 共享，甚至可以跨平台（例如网页端和 APP 端）。

10 如何注销session?

1、手动注销（模拟用户注销）

	HttpSession session = req.getSession();
    session.removeAttribute("user");
    // 注销session
    session.invalidate();

2 自动注销，超时注销 在Tomcat的web.xml中设置，默认30分钟

<!--  设置session的默认的失效时间  -->
<session-config>
<!--    1分钟后失效，默认单位为分钟    -->
    <session-timeout>1</session-timeout>
</session-config>

11 各层协议与http协议的关系：

首先发给DNS服务器，进行域名解析，得到IP地址，然后生成针对目标web服务器的Http请求报文，然后报文由Tcp协议负责传输，为了方便，Http请求报文被分为报文段，然后每个报文段可靠的传输给对方，然后报文段由ip层负责一边中转一边传送，服务器收到报文段后重组报文段，然后由应用层的Http协议处理请求的内容，请求的结果以同样的方式进行回传。

12 HTTPS 的流程、SSL 是什么、什么是非对称加密、对称加密、RSA 具体实现。

12.1.SSL是什么？

（1）SSL，英文全拼是Secure Sockets Layer ，即安全套接层，SSL是为我们网络通信提供安全及数据完整性的一种安全协议，它可以在传输层对网络连接进行加密，使我们的访问更安全可靠。

（2）信息安全主要保证三个方面的安全，数据的保密性，数据的完整性，身份认证。SSL安全协议就解决这三个问题。

第一，ssl可以防止被黑客窃听数据。（数据的保密性）

第二，ssl可以防止数据在传输过程中被黑客肆意篡改，保证数据传输的完整性。例如您在网上购物或登录网上银行时，如果您的数据被黑客篡改，将极可能造成重大的金钱损失，因此，使用SSL是十分有必要的。（数据的完整性）

第三，身份认证（ca机构）

12.2 什么是对称加密，什么是非对称加密

对称加密：就是客户端和服务器共用同一个密钥，该密钥可以用于加密一段内容，同时也可以用于解密这段内容。对称加密的优点是加解密效率高，但是在安全性方面可能存在一些问题，因为密钥存放在客户端有被窃取的风险。

非对称加密：
密钥分成了两种：公钥和私钥。公钥通常存放在客户端，私钥通常存放在服务器。使用公钥加密的数据只有用私钥才能解密，反过来使用私钥加密的数据也只有用公钥才能解密。非对称加密的优点是安全性更高，因为客户端发送给服务器的加密信息只有用服务器的私钥才能解密，因此不用担心被别人破解，但缺点是加解密的效率相比于对称加密要差很多

12.3 RSA实现原理（大体）

具体实现参考 https://www.cnblogs.com/rinack/p/12420735.html

1. 什么是RSA RSA算法是现今使用最广泛的公钥密码算法，也是号称地球上最安全的加密算法。在了解RSA算法之前，先熟悉下几个术语 根据密钥的使用方法，可以将密码分为对称密码和公钥密码 对称密码：加密和解密使用同一种密钥的方式

公钥密码：加密和解密使用不同的密码的方式，因此公钥密码通常也称为非对称密码。

2. RSA加密 RSA的加密过程可以使用一个通式来表达

密文＝明文EmodN 也就是说RSA加密是对明文的E次方后除以N后求余数的过程。就这么简单？对，就是这么简单。
从通式可知，只要知道E和N任何人都可以进行RSA加密了，所以说E、N是RSA加密的密钥，也就是说E和N的组合就是公钥，我们用(E,N)来表示公钥

公钥＝(E,N)
不过E和N不并不是随便什么数都可以的，它们都是经过严格的数学计算得出的，关于E和N拥有什么样的要求及其特性后面会讲到。顺便啰嗦一句E是加密（Encryption）的首字母，N是数字（Number）的首字母

3. RSA解密 RSA的解密同样可以使用一个通式来表达

明文＝密文DmodN
也就是说对密文进行D次方后除以N的余数就是明文，这就是RSA解密过程。知道D和N就能进行解密密文了，所以D和N的组合就是私钥

私钥＝(D,N) 从上述可以看出RSA的加密方式和解密方式是相同的，加密是求“E次方的mod N”;解密是求“D次方的mod N”
此处D是解密（Decryption）的首字母；N是数字（Number）的首字母。

公钥 （E，N） 私钥 （D，N） 密钥对 （E，D，N） 加密 密文＝明文EmodN密文＝明文EmodN 解密 明文＝密文DmodN

12.3 Https的流程，为什么要有CA认证机构，CA认证机构如何保证安全可信？
参考https://mp.weixin.qq.com/s/21JaXwdfSjItj5SgOwhapg
12.3.1 流程：

1 用户在浏览器发起HTTPS请求（如 https://www.mogu.com/），默认使用服务端的443端口进行连接；

2 HTTPS需要使用一套CA数字证书，证书内会附带一个公钥Pub，而与之对应的私钥Private保留在服务端不公开；

3 服务端收到请求，返回配置好的包含公钥Pub的证书给客户端；

4
客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效（递归判断，直到判断到系统内置或浏览器配置好的根证书），如果不通过，则显示HTTPS警告信息，如果通过则继续；

5 客户端生成一个用于对称加密的随机Key，并用证书内的公钥Pub进行加密，发送给服务端；

6 服务端收到随机Key的密文，使用与公钥Pub配对的私钥Private进行解密，得到客户端真正想发送的随机Key；

7 服务端使用客户端发送过来的随机Key对要传输的HTTP数据进行对称加密，将密文返回客户端；

8 客户端使用随机Key对称解密密文，得到HTTP数据明文；

9 后续HTTPS请求使用之前交换好的随机Key进行对称加解密。

12.3.2 为什么Https要进行对称加密和非对称加密?只进行对称加密或者非对称加密不可以吗

对称加密是指有一个密钥，用它可以对一段明文加密，加密之后也只能用这个密钥来解密得到明文。如果通信双方都持有密钥，且天知地知你知我知，绝对不会有别的人知道，那么通信安全自然是可以得到保证的（在密钥足够强的情况下）。

然而，在HTTPS的传输场景下，服务端事先并不知道客户端是谁，你也不可能在事先不通过互联网和每一个网站的管理员都悄悄商量好一个通信密钥出来，那么必然存在一个密钥在互联网上传输的过程，如果在传输过程中被别人监听到了，那么后续的所有加密都是无用功。

这时，我们就需要另一种神奇的加密类型，非对称加密。

非对称加密有两个密钥，一个是公钥，另一个是私钥。一般来说，公钥用来加密，这时密文只能用私钥才能解开。

那么，当客户端发起连接请求，服务端将公钥传输过去，客户端利用公钥加密好信息，再将密文发送给服务端，服务端里有私钥可以解密。

但是，当服务端要返回数据，如果用公钥加密，那么客户端并没有私钥用来解密，而如果用私钥加密，客户端虽然有公钥可以解密，但这个公钥之前就在互联网上传输过，很有可能已经有人拿到，并不安全，所以这一过程只用非对称加密是不能满足的。
进行两次非对称加密是安全的，但是非对称加密效率很差。

12.3.3为什么要有CA机构认证，作用是什么？如何保证安全？

依然考虑中间人攻击的情况，非对称加密的算法都是公开的，所有人都可以自己生成一对公钥私钥。

当服务端向客户端返回公钥A1的时候，中间人将其替换成自己的公钥B1传送给浏览器。

而浏览器此时一无所知，傻乎乎地使用公钥B1加密了密钥K发送出去，又被中间人截获，中间人利用自己的私钥B2解密，得到密钥K，再使用服务端的公钥A1加密传送给服务端，完成了通信链路，而服务端和客户端毫无感知。

出现这一问题的核心原因是客户端无法确认收到的公钥是不是真的是服务端发来的。为了解决这个问题，互联网引入了一个公信机构，这就是CA。

服务端在使用HTTPS前，去经过认证的CA机构申请颁发一份数字证书，数字证书里包含有证书持有者、证书有效期、公钥等信息，服务端将证书发送给客户端，客户端校验证书身份和要访问的网站身份确实一致后再进行后续的加密操作。但是，如果中间人也聪明一点，只改动了证书中的公钥部分，客户端依然不能确认证书是否被篡改，这时我们就需要一些防伪技术了。
前面说过，非对称加密中一般公钥用来加密，私钥用来解密，虽然私钥加密理论上可行，但由于数学上的设计这么做并不适合，那么私钥就只有解密这个功能了么？

私钥除了解密外的真正用途其实还有一个，就是数字签名，其实就是一种防伪技术，只要有人篡改了证书，那么数字签名必然校验失败。具体过程如下

CA机构拥有自己的一对公钥和私钥

CA机构在颁发证书时对证书明文信息进行哈希

将哈希值用私钥进行加签，得到数字签名

明文数据和数字签名组成证书，传递给客户端。 客户端得到证书，分解成明文部分Text和数字签名Sig1

用CA机构的公钥进行解签，得到Sig2（由于CA机构是一种公信身份，因此在系统或浏览器中会内置CA机构的证书和公钥信息）

用证书里声明的哈希算法对明文Text部分进行哈希得到H

当自己计算得到的哈希值T与解签后的Sig2相等，表示证书可信，没有被篡改这时，签名是由CA机构的私钥生成的，中间人篡改信息后无法拿到CA机构的私钥，保证了证书可信。

12.3.4HTTPS绝对安全吗？

J2EE相关：
1 WebSocket 是什么。

webSocket是HTML5的一种新协议，先通过HTTP/HTTPS协议进行握手后创建一个用于交换数据的TCP连接，服务器与客户端通过此TCP连接进行实时通信，实现了服务器与客户端的双向通信。

应用场景：需要提供多个用户相互交流或者实时的展示服务器端需要经常变动的数据，如社交类应用，在线教育等。

2 Servlet、Filter 和 Listener 分别是什么，用在什么地方，JSP 页面如何进行处理。（参考了知乎bravo1988）

1 Servlet

1.1servlet是web开发中的一个标准，一个规范，主要是交互式地浏览和修改数据，生成动态Web内容,若想开发一个动态WEB资源，需要完成以下2个步骤：
编写一个Java类，实现Servlet接口,实现业务逻辑； 把开发好的Java类部署到WEB服务器中。

1.2 Servlet生命周期 1 Servlet对象是用户第一次访问时创建，对象创建之后就驻留在内存里面了，响应后续的请求。 2 Servlet对象一旦被创建，init()方法就会被执行， 3 客户端的每次请求导致service()方法被执行， 4
Servlet对象被摧毁时(Web服务器停止后或者Web应用从服务器里删除时)，destory()方法就会被执行。由jvm进行垃圾回收。

1.3 Servlet 中，调用 JSP 展示元素和返回 String（即 api，一般是 json 数据）有什么区别。

1.4 Servlet 是否是线程安全的。

Servlet不是线程安全的。
原因：当Tomcat接收到Client的HTTP请求时，Tomcat从线程池中取出一个线程，之后找到该请求对应的Servlet对象并进行初始化，之后调用service()方法。要注意的是每一个Servlet对象再Tomcat容器中只有一个实例对象，即是单例模式。如果多个HTTP请求的是同一个Servlet，那么着两个HTTP请求对应的线程将并发调用Servlet的service()方法。可能就会造成并发问题，一般造成线程安全主要问题在于实例变量造成的，因此在编写servlet是尽量避免使用实例变量，在必须使用到实例变量的时候尽量使用同步锁的保护使用的实例变量
2 Filter

当浏览器访问服务器中的目标资源时，会被Filter拦截，在Filter中进行预处理操作，然后再将请求转发给目标资源。当服务器接收到这个请求后会对其进行响应，在服务器处理响应的过程中，也需要先将响应结果发送给拦截器，在拦截器中对响应结果进行处理后，才会发送给客户端。

其实，Filter过滤器就是一个实现了javax.servlet.Filter接口的类，在javax.servlet.Filter接口中定义了三个方法，具体如下。
原理：首先初始化过滤器，然后服务器组织过滤器链，所有的请求都必须需要先通过过滤器链，
过滤器链是一个栈，遵循先进后出的原则 ，所有的请求需要经过一个一个的过滤器，执行顺序要根据web.xml里配置的的位置前后执行，每个过滤器之间通过chain.doFilter连接， 最后抵达真正请求的资源，执行完后再从过滤器链退出

Filter使用场景：可以记录用户的访问操作，将用户的访问信息保存到数据库（用户id，url，日期等），权限控制，防止用户访问未被授权的东西。

3 Listener

Listener是Servlet提供的扩展点，一般用于对特定对象的生命周期和特定事件进行响应处理。如HttpSessionListener，可以用于追踪Session创建和销毁这两个生命周期。如HttpSessionAttributeListener，用于追踪Session上的Attribute，添加移除替换这三种事件。有了这些扩展点，我们做一些功能的时候就比较方便，如检测在线人数就可以使用HttpSessionListener，当Session创建时在线人数+1，Session销毁时在线人数-1

应用场景：可以统计在线人数
实现:观察者模式

4 JSP页面如何进行处理
1 jsp是什么？Java Server Page 运行在服务器端的页面 Jsp=Html+Java
2 如何处理？没有jsp之前，直接在Servlet中一行行输出代码，给web容器，然后返回给浏览器，
有了jsp之后，就变成了
（1）客户端通过浏览器向服务器发出请求，该请求中包含了请求的资源的路径
（2）服务器根据被加载的客户端的请求加载被请求的JSP页面
（3）Web服务器中的JSP引擎把被加载的JSP页面转换成servlet
（4）JSP引擎把生成的JSP页面编译成class文件
（5）服务器执行这个class文件
（6）服务器把执行结果发送给浏览器显示

5 Redirect和Forwod之间的区别？

> 转发是服务器行为，重定向是客户端行为。 转发（Forword） 通过RequestDispatcher对象的
> forward（HttpServletRequest request,HttpServletResponse response）
> 方法实现的。 RequestDispatcher 可以通过 HttpServletRequest 的
> getRequestDispatcher() 方法获得。例如下面的代码就是跳转到 login_success.jsp 页面。
> 重定向（Redirect） 是利用服务器返回的状态吗来实现的。客户端浏览器请求服务器的时候，服务器会返回一个状
> 态码。服务器通过HttpServletRequestResponse的setStatus(int
> status)方法设置状态码。如果服务器返回301或者 302，则浏览器会到新的网址重新请求该资源。
> request.getRequestDispatcher("login_success.jsp").forward(request,
> response);
> 1. 从地址栏显示来说: forward是服务器请求资源,服务器直接访问目标地址的URL,把那个URL的响应内容读取过来, 然后把这些内容再发给浏览器.浏览器根本不知道服务器发送的内容从哪里来的,所以它的地址栏还是原来的地址.
> redirect是服务端根据逻辑,发送一个状态码,告诉浏览器重新去请求那个地址.所以地址栏显示的是新的URL.
> 2. 从数据共享来说: forward:转发页面和转发到的页面可以共享request里面的数据. redirect:不能共享数据. 
3. 从运用地方来说: forward:一般用于用户登陆的时候,根据角色转发到相应的模块. redirect:一般用于用户注销登
> 陆时返回主页面和跳转到其它的网站等
> 4. 从效率来说: forward:高. redirect:低

什么时候使用：原则上： 要保持request域的数据时使用转发，要访问外站资源的时候用重定向，其余随便；

nginx + tomcat 模式下，服务器段如何获取客户端请求 IP 。

难点：Nginx反向代理后，Servlet应用通过request.getRemoteAddr()取到的IP是Nginx的IP地址，并非客户端真实IP，通过request.getRequestURL()获取的域名、协议、端口都是Nginx访问Web应用时的域名、协议、端口，而非客户端浏览器地址栏上的真实域名、协议、端口。
（1）由于Nginx是代理服务器，所有客户端请求都从Nginx转发到Jetty/Tomcat，如果Nginx不把客户端真实IP、域名、协议、端口告诉Jetty/Tomcat，那么Jetty/Tomcat应用永远不会知道这些信息，所以需要Nginx配置一些HTTP Header来将这些信息告诉被代理的Jetty/Tomcat；
（2）Jetty/Tomcat这一端，不能再获取直接和它连接的客户端（也就是Nginx）的信息，而是要从Nginx传递过来的HTTP Header中获取客户端信息。

传输层协议

UDP/TCP区别。

1、TCP面向连接的，需要三次握手建立链接，四次挥手断开链接，所谓链接就是客户端与服务器端之间共同维护的一些字段的状态（Socket，窗口大小，序列号）。UDP是无连接的，远地主机在收到UDP报文段后，不需要给出确认，一般适用于即时通讯。
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付，也同时由于
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6 TCP应用于FTP,HTTP，UDP应用DNS，视频，广播通信。

TCP

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议
面向连接：一定是「一对一」才能连接，不能像 UDP 协议 可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；

可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；

字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节已经收到，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。

TCP 三次握手。
TCP 通过三次握手建立连接。

1 一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态
2 客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
3 服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
4 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。
5 服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。
第三次握手是可以携带数据的，前两次握手是不可以携带数据的，

为什么不是两次握手或者四次握手？
「两次握手」：无法防止历史连接的建立（首要原因），会造成双方资源的浪费，也无法可靠的同步双方序列号；

避免历史连接：

客户端连续发送多次 SYN 建立连接的报文，在网络拥堵等情况下：
一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；
那么此时服务端就会回一个 SYN + ACK 报文给客户端；
客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。
如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：

如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；

如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接；

同步双方初始序列号
列号在 TCP 连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的 SYN 报文的时候，需要服务端回一个 ACK 应答报文，表示客户端的 SYN 报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。
而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
避免浪费资源
两次握手会造成消息滞留情况下，服务器重复接受无用的连接请求 SYN 报文，而造成重复分配资源。

「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

问什么断开连接是四次挥手？
断开连接：双方都可以主动断开连接，断开连接后主机中的「资源」将被释放。
什么是四次挥手？

客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1
状态。

服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。

客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。

等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。

客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态

服务器收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。

客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态

为什么四次挥手？

关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。

服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN
报文给客户端来表示同意现在关闭连接。

什么是 TIME-WAIT、

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。

需要 TIME-WAIT 状态，主要是两个原因：

1 防止具有相同「四元组」的「旧」数据包被收到；

如上图黄色框框服务端在关闭连接之前发送的 SEQ = 301 报文，被网络延迟了。
这时有相同端口的 TCP 连接被复用后，被延迟的 SEQ = 301
抵达了客户端，那么客户端是有可能正常接收这个过期的报文，这就会产生数据错乱等严重的问题。
TCP 就设计出了这么一个机制，经过 2MSL(报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃) 这个时间，足以让两个方向上的数据包都被丢弃，使得原来连接的数据包在网络中都自然消失，再出现的数据包一定都是新建立连接所产生的。

2 保证「被动关闭连接」的一方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭；客户端四次挥手的最后一个 ACK 报文如果在网络中被丢失了，此时如果客户端 TIME-WAIT 过短或没有，则就直接进入了 CLOSE 状态了，那么服务端则会一直处在 LASE-ACK 状态。
当客户端发起建立连接的 SYN 请求报文后，服务端会发送 RST 报文给客户端，连接建立的过程就会被终止。
如果 TIME-WAIT 等待足够长的情况就会遇到两种情况：

服务端正常收到四次挥手的最后一个 ACK 报文，则服务端正常关闭连接。

服务端没有收到四次挥手的最后一个 ACK 报文时，则会重发 FIN 关闭连接报文并等待新的 ACK 报文。

为什么不可以是三次挥手、

这个因为第一次挥手表示客户端发送了一个fin的包，表示客户端已发送数据完毕，但是服务端这个时候可能还有数据没有发送完成，先发送给客户端一个ask的包，等待自己的数据发送完成才能向客户端发送一个 fin的包，表示自己的数据也已发送完成。这样中间就必须为两次来发送ack和fin。

流量控制

双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。
如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。
对发送方发送速率的控制，我们称之为流量控制。
TCP利用滑动窗口进行流量控制。

滑动窗口（发送方维护）

接收方告诉发送方我还能接受多少数据，然后发送方就可以根据这个信息来进行数据的发送。

以下是发送方维护的窗口，就是黑色圈起来的。

如果接收方回复的窗口一直是 0 怎么办？
会发送一个包去探测探测这个接收方到底行不行，可以发送多次，然后还有间隔时间，多次之后都不行可以直接 RST(重置连接)。
假设接收方每次回应窗口都很小怎么办？
存着，养肥了，再发。

Nagle 算法

nagle算法会延迟数据包的发送，仅仅对发送队列中最后一个数据包（未完成的数据包）起作用。其目的是解决大量的小包造成网络负担上升的问题，方法是囤积数据到满足条件为止，然后发送大数据包。

糊涂窗口综合症

发送方和接收方都没有感知到窗口滑动的值非常小，而是选择继续按原有逻辑滑动窗口，也就是说它只负责可靠性和流量控制，并不关心小包造成的效率问题。

超时重传
如果发生丢包，就要重传，超时重传，就是如果超过一个时间还没有得到ack，就重传。

快速重传

超时重传是按时间来驱动的，如果是网络状况真的不好的情况，超时重传没问题，但是如果网络状况好的时候，只是恰巧丢包了，那等这么长时间就没必要。
快速重传，就是发送方如果连续三次收到对方相同的确认号，那么马上重传数据。因为连续收到三次相同 ACK 证明当前网络状况是 ok 的，那么确认是丢包了，于是立马重发，没必要等这么久。

Sack
解决的问题：过我发送1、2、3、4这4个包，就 2 对方没收到，1、3、4都收到了，然后不管是超时重传还是快速重传反正对方就回 ACK 2。这时候要重传 2、3、4 呢还是就 2 呢？

SACK 就是接收方会回传它已经接受到的数据，这样发送方就知道哪一些数据对方已经收到了，所以就可以选择性的发送丢失的数据。

D-SACK

使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了;

拥塞控制

加了拥塞控制是因为 TCP
不仅仅就管两端之间的情况，还需要知晓一下整体的网络情形，否则网络拥堵，收不到ack，就越发的不断重传，就越来越堵。
怎么解决？

1、慢启动，探探路。

2拥塞避免，感觉差不多了减速看看

3、拥塞发生快速重传/恢复

慢启动，就是新司机上路慢慢来，初始化 cwnd（Congestion Window）为 1，然后每收到一个 ACK 就 cwnd++
并且每过一个 RTT ，cwnd = 2*cwnd 。

线性中带着指数，指数中又夹杂着线性增。

然后到了一个阈值，也就是 ssthresh（slow start threshold）的时候就进入了拥塞避免阶段。

这个阶段是每收到一个 ACK 就 cwnd = cwnd + 1/cwnd并且每一个 RTT 就 cwnd++。

可以看到都是线性增。

然后就是一直增，直到开始丢包的情况发生，前面已经分析到重传有两种，一种是超时重传，一种是快速重传。

如果发生超时重传的时候，那说明情况有点糟糕，于是直接把 ssthresh 置为当前 cwnd 的一半，然后 cwnd 直接变为
1，进入慢启动阶段。
如果是快速重传，那么这里有两种实现，一种是 TCP Tahoe ，和超时重传一样的处理。

一种是 TCP Reno，这个实现是把 cwnd = cwnd/2 ，然后把 ssthresh 设置为当前的 cwnd 。

然后进入快速恢复阶段，将 cwnd = cwnd + 3（因为快速重传有三次），重传 DACK （接受三次ack的seq）指定的包，如果再收到一个DACK则cwnd++，如果收到是正常的 ACK 那么就将 cwnd 设为 ssthresh 大小，进入拥塞避免阶段。

长连接 VS 短连接、应用场景是什么。
一、长连接与短连接：

长连接：client方与server方先建立连接，连接建立后不断开，然后再进行报文发送和接收。这种方式下由于通讯连接一直存在。
短连接：Client方与server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此方式常用于一点对多点通讯。
二、长连接与短连接的操作过程： 短连接的操作步骤是：建立连接——数据传输——关闭连接…建立连接——数据传输——关闭连接；
长连接的操作步骤是：建立连接——数据传输…（保持连接）…数据传输——关闭连接 三、长连接与短连接的使用时机：
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。每个TCP连接的建立都需要三次握手，每个TCP连接的断开要四次握手。如果每次操作都要建立连接然后再操作的话处理速度会降低，所以每次操作下次操作时直接发送数据就可以了，不用再建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，频繁的socket创建也是对资源的浪费。
短连接：web网站的http服务一般都用短连接。因为长连接对于服务器来说要耗费一定的资源。像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。试想如果都用长连接，而且同时用成千上万的用户，每个用户都占有一个连接的话，可想而知服务器的压力有多大。所以并发量大，但是每个用户又不需频繁操作的情况下需要短连接。
总之：长连接和短连接的选择要视需求而定。

网络层协议：

其他：

网络模型分层

DNS、ARP 协议原理。

DNS： 作者：wuxinliulei

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服务器地址(http://qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找http://qq.com域服务器，重复上面的动作，进行查询，直至找到www
. qq .com主机。
6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。

ARP： ARP协议就是起到在IP地址到对应的硬件地址之间提供映射作用的，所以ARP协议又叫地址解析协议。 目标IP与自己在同一网段

arp高速缓存有目标IP的MAC地址：直接发送到该物理地址
arp高速缓存没有目标IP的MAC地址：发送ARP广播请求目标IP的MAC地址，缓存该MAC地址，然后发数据报到该MAC地址。

目标IP与自己不在同一个网段 这种情况需要将包发给默认网关，所以主要获取网关的MAC地址

arp高速缓存有默认网关的MAC地址：直接发送IP数据报道默认网关，再由网关转发到外网。 arp高速缓存没有默认网关的MAC地址
：还是发送ARP广播请求默认网关的MAC地址，缓存该地址，并且发送数据报到网关。

地址栏输入 URL 发生了什么。

ICMP协议：(ping的原理)

ping是基于ICMP协议 ICMP 主要的功能包括：确认 IP 包是否成功送达目标地址、报告发送过程中 IP
包被废弃的原因和改善网络设置等。 主机 A 向主机 B 发送了数据包，由于某种原因，途中的路由器 2 未能发现主机 B 的存在，这时，路由器
2 就会向主机 A 发送一个 ICMP 目标不可达数据包，说明发往主机 B 的包未能成功。

ICMP 的这种通知消息会使用 IP 进行发送 。

因此，从路由器 2 返回的 ICMP 包会按照往常的路由控制先经过路由器 1 再转发给主机 A 。

收到该 ICMP 包的主机 A 则分解 ICMP 的首部和数据域以后得知具体发生问题的原因。

什么是DOS攻击，如何解决

拒绝服务，即无法及时接收并处理外界合法请求。 SYN洪攻击属于DOS攻击 解决方法：设置SYN
Cookie，就是给每一个请求连接的IP地址分配一个Cookie，或者对每一个请求连接的IP地址都进行记录，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，以后从这个IP地址来的包会被一概丢弃。

DNS 欺骗如何解决

DNS欺骗就是攻击者冒充域名服务器的一种欺骗行为
DNS服务器利用缓存中的记录信息回答查询请求或是DNS服务器通过查询其他服务获得查询信息并将它发送给客户机，这两种查询成为递归查询，这种查询方式容易导致DNS欺骗。
保护内部设备：像这样的攻击大多数都是从网络内部执行攻击的，如果你的网络设备很安全，那么那些感染的主机就很难向你的设备发动欺骗攻击。
不要依赖DNS：在高度敏感和安全的系统，你通常不会在这些系统上浏览网页，最后不要使用DNS。如果你有软件依赖于主机名来运行，那么可以在设备主机文件里手动指定。
使用入侵检测系统：只要正确部署和配置，使用入侵检测系统就可以检测出大部分形式的ARP缓存中毒攻击和DNS欺骗攻击。

SQL注入

SQL注入即是指web应用程序对用户输入数据的合法性没有判断或过滤不严，攻击者可以在web应用程序中事先定义好的查询语句的结尾上添加额外的SQL语句
如何防范： 1 代码层防止sql注入攻击的最佳方案就是sql预编译（jdbc prepared）
2. 确认每种数据的类型，比如是数字，数据库则必须使用int类型来存储
3. 规定数据长度，能在一定程度上防止sql注入
4. 过滤参数中含有的一些数据库关键词

XSS

跨站脚本攻击，指恶意攻击者添加一些代码，嵌入到web页面中去。使别的用户访问都会执行相应的嵌入代码。
从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。 防范：利用Filter对输入(和URL参数)进行过滤，对输出进行编码

CSRF

1、概念：攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。
举例：示例1：银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000危险网站B，它里面有一段HTML的代码如下<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
首先，你登录了银行网站A，然后访问危险网站B，噢，这时你会发现你的银行账户少了1000块…为什么会这样呢？原因是银行网站A违反了HTTP规范，使用GET请求更新资源。在访问危险网站B的之前，你已经登录了银行网站A，而B中的以GET的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站A的Cookie发出Get请求，去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”，结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作…
2、主要攻击手段：img等标签跨域GET请求、POST自动表单提交
3、主要防御手段：
（1） 服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数。
（2).验证码这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，厄…这个方案可以完全解决CSRF，但个人觉得在易用性方面似乎不是太好，还有听闻是验证码图片的使用涉及了一个被称为MHTML的Bug，可能在某些版本的微软IE中受影响。

如何判断远程机器上某个端口是否开启，项目中需要查看域名在本地的解析 IP ，如何操作。

telnet baidu.com 80
　　Trying 123.125.114.144...
　　Connected to baidu.com (123.125.114.144). #==>出现Connected表示连通了，说明百度的80端口开放的

# ifconfig        
eth0   Link encap:Ethernet HWaddr 00:50:56:0A:0B:0C 
     inet addr:192.168.0.3 Bcast:192.168.0.255 Mask:255.255.255.0
     inet6 addr: fe80::250:56ff:fe0a:b0c/64 Scope:Link
     UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
     RX packets:172220 errors:0 dropped:0 overruns:0 frame:0
     TX packets:132379 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:1000 
     RX bytes:87101880 (83.0 MiB) TX bytes:41576123 (39.6 MiB)
     Interrupt:185 Base address:0x2024 

lo    Link encap:Local Loopback 
     inet addr:127.0.0.1 Mask:255.0.0.0
     inet6 addr: ::1/128 Scope:Host
     UP LOOPBACK RUNNING MTU:16436 Metric:1
     RX packets:2022 errors:0 dropped:0 overruns:0 frame:0
     TX packets:2022 errors:0 dropped:0 overruns:0 carrier:0
     collisions:0 txqueuelen:0 
     RX bytes:2459063 (2.3 MiB) TX bytes:2459063 (2.3 MiB)