计算机网络
TCP三次握手
1.为什么要三次握手两次不行吗？
主要是避免客户端发送请求如果得不到服务器端相应会重发请求，服务器段建立链接，此时如果失效请求又到达服务器段，服务器重新建立好链接，TCP链接进入established状态，那么服务器的资源就会被浪费。
三次握手建立链接，服务器发送syn的作用是：
因为客户端发送的 syn 可能过了好久才到达服务端，而此时客户端超时重传的 SYN 已 经到达服务端，那么后来的 SYN 就是无效的，如果不发第二个 syn 查询客户端是否有效的 话，服务端就会监听这个延迟到达的请求，造成资源的浪费。所以可以强制发送一个 SYN 询问客户端之前的请求是否有效。
2.TCP为什么要4次挥手。
1.确保数据能够完成传输
time-wait状态存在的原因： 客户端发送ACK可能存在丢失，服务器会重新发送FIN， client保持客户端链接目的就是，能够重新发送ACK，保证服务端链接能够正常关闭。
2.TIME-WAIT的时间通常为两个报文的呼吸时间2MSL，通常为1～4分钟。
3.如果大量的socket在time-wait状态怎么办。a.将短链接，变成长链接。b.修改数据的超市时间。
netstat查看TCP状态
client经历的TCP链接状态如下：
server经历的TCP链接状态如下：
这两个队列是内核实现的，当服务器 绑定、监听了某个端口后，这个端口的 SYN 队列(未完成握手队列)和 ACCEPT 队列(已 完成握手队列)就建立好了。客户端使用 connect 向服务器发起 TCP 连接，当图中 1.1 步 骤客户端的 SYN 包到达了服务器后，内核会把这一信息放到 SYN 队列中，同时回一个 SYN+ACK 包给客户端。一段时间后，在图中 2.1 步骤中客户端再次发来了针对服务器 SYN 包的 ACK 网络分组时，内核会把连接从 SYN 队列中取出，再把这个连接放到 ACCEPT 队列中。而服务器在第 3 步调用 accept 时，其实就是直接从 ACCEPT 队列中取出已经建 立成功的连接套接字而已。
Socket常见函数
1.创建serverSocket
2.bing (ip, port)
3. listen(serversocket的文件描述符，全链接队列长度），（设置里全链接队列长度），此时如果有请求来，内核已经帮助完成三次握手。
4. 在执行accept函数前就完成了
5. accept()函数从全连接队列取出一个socket连接，并绑定一个描述符d。（代表着服务端与客户端的连接）。
6. 利用文件描述符fd，收发数据。
6.close函数，发生4次挥手。（客户端发送FIN, 进入FIN_WAIT_1状态， 收到ack进入FIN_WAIT_2状态，因为一般server会直接发回ACK, 所以WAIT1状态很难见到, 收到ACK后，客户端进入FIN_WAIT_2状态，server进入ClOSE_WAIT状态，表示还有数据要发送，server发送完数据，发送和FIN报文， 客户端接收到FIN报文后，发送给服务端ACK， 变成TIME_WAIT状态， TIME_WAIT一般存在两个2MSL时间，原因是避免发送给服务端的ACK丢失，继续接收到服务端PIN请求，无法处理。保证Server端连接能够关闭。
TCP如何保证可靠传输
报文功能讲解：http://blog.chinaunix.net/uid-26413668-id-3408115.html
1、确认和重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。
2、数据校验，（接收端会做检验和校验）
3、数据合理分片和排序：
UDP：IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报.
tcp会按MTU合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层。
4、流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。
5、拥塞控制：当网络拥塞时，减少数据的发送。
TCP 三次握手有哪些漏洞?
SYN-FLOOD洪范攻击：
原理:
攻击者首先伪造地址对 服务器发起 SYN 请求，服务器回应(SYN+ACK)包，而 真实的 IP 会认为，我没有发送请求，不作回应。服务 器没有收到回应，这样的话，服务 器不知 道(SYN+ACK)是否发送成功，默认情况下会重试 5 次(tcp_syn_retries)。这样的 话，对于服务器的内存，带宽都有很大的消耗。攻击者 如果处于公网，可以伪造 IP 的话， 对于服务器就很难根据 IP 来判断攻击者，给防护带来很大的困难。
服务端会维护一个非常的的半连接队列，消耗CPU和内存。
解决：
Syn Cache 技术： 这种技术在收到 SYN 时不急着去分配系统资源，而是先回应一个 ACK 报文，并在一 个专用的 HASH 表中(Cache)中保存这种半开连接，直到收到正确的 ACK 报文再去分配 系统。
硬件防火墙：SYN FLOOD 攻击很容易就能被防火墙拦截。
XSS攻击
https://imooc.com/article/67689
https://blog.****.net/ghsau/article/details/17027893
XSS即跨站点脚本攻击，只要浏览器加载，解析，执行了意料之外的JS，CSS等都可以被认为是受到了 XSS攻击，而 XSS攻击的分类主要有“反射型”与“存储型”两种。
a. 对输入内容的特定字符进行编码，例如表示 html标记的 < > 等符号。
b. 对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie，此 HTTP头由服务端设置。(js脚本无法获取到cookies)
c .将不可信的值输出 URL参数之前，进行 URLEncode操作，而对于从 URL参数中获取值一定要进行格式检测（比如你需要的时URL，就判读是否满足URL格式）。
d .不要使用 Eval来解析并运行不确定的数据或代码，对于 JSON解析请使用 JSON.parse() 方法。
CSRF攻击（跨域请求伪造）
攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。
CSRF原理：
CSRF的防御办法
1.就是在客户端页面增加伪随机数。中心思想就是在所有请求上加上随机数token，并在服务器段验证token。 token可以存放在服务器session中，也可以实时计算。
原理: 个人理解， 就是利用服务端增加验证机制。客户端处理cookie。
第一步：服务端设置hash值。
第二步： 客户端处理cookie，并在发送请求时，带着处理后的值。
在表单里增加Hash值，以认证这确实是用户发送的请求。
<input type=”hidden” name=”hash” value=”<?=$hash;?>”>
第三步： 服务端校验处理后的值。
2.验证请求中的Referer字段。
这篇博客说的比较好： 其实就是在第三方网站上，referer字段还是自己的，referer字段在http的头中，在服务器端进行referer验证，不过referer还是可以伪造，或者在浏览器端被禁用。
https://blog.****.net/u012322925/article/details/51290054?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.control
3.避免全局cookies，严格设定cookies域。
cookies：
Cookie 的内容主要包括:名字，值，过期时间，域和路径。
标准格式:Set-Cookie: NAME=VALUE;Expires=DATE;Path=PATH; Domain=DOMAIN_NAME;SECURE;
举例说明:Set-Cookie: JSESSIONID=mysession; Expires=Thu, 05-Jun-2 008 05:02:50 GMT; Path=/web;
Cookie 的 Expires 属性标识了 Cookie 的有效时间，当 Cookie 的有效时间过了之后， 这些数据就被自动删除了。若不设置过期时间，则表示这个 cookie 的生命期为浏览器会话 期间，关闭浏览器窗口，cookie 就消失。 这种生命期为浏览器会话期的 cookie 被称为会话 cookie(临时性 cookie)，会话 cookie 保存在内存里。 若设置了过期时间，浏览器 就会把 cookie 保存到硬盘上，关闭后再次打开浏览器，这些 cookie 仍然有效直到超过设 定的过期时间。存储在硬盘上的 cookie 可以在不同的浏览器进程间共享，比如两个 IE 窗口。
4. 设置cookies时间，
Cookie cookie = new Cookie(“username”,“helloweenvsfei”); // 新建 Cookie cookie.setMaxAge(Integer.MAX_VALUE); // 设置生命周期为 MAX_VALUE，
如果设置时间大于0持久化，小于0临时cookies， 等于0，删除cookies。
说下TCP的黏包，TCP的黏包简单理解
1.产生原因：
a. 发送端避免频繁发送较小的数据包时，由于包头的存在，会增大网络开销，一般会使用Nagle算法，（Nagle 算法就是当有数据要发送时，先 不立即发送，而是稍微等一小会，看看在这一小段时间内，还有没有其他需要发送的消息。 当等过这一小会以后，再把要发送的数据一次性都发出去。这样就可以有效的减少包头的 发送次数）
b. 接收方应用层过慢的从TCP缓存区取数据放到，造成黏包。
2. TCP 报文粘连的解决方法:
a.关闭 Nagle 算法。在 scoket 选项中，TCP_NODELAY 表示是否使用 Nagle 算法。
b.接收端尽可能快速的从缓冲区读数据。
c.可以在发送的数据中，添加一个表示数据的开头和结尾的字符，在收到消息后，通过这 些字符来处理报文粘连。
Http 状态码含义
200 OK 服务器已成功处理了请求并提供了请求的网页。
301 Moved Permanently 永久性重定向。请求的网页已永久移动到新位置。
302(或 307) Moved Temporatily 临时性重定向。请求的网页临时移动到新位置。
304 Not Modified 未修改。自从上次请求后，请求的内容未修改过。命中缓存。
401 Unauthorized 客户试图未经授权访问受密码保护的页面。应答中会包含一个 WWW-Authenticate 头，浏览器据此显示用户名字/密码对话框，然后在填写合适的 Authorization 头后再次发出请求，需要认证。
403 Forbidden 服务器拒绝请求。
404 Not Found 服务器上不存在客户机所请求的资源。
500 Internal Server Error 服务器遇到一个错误，使其无法为请求提供服务。
504，502网关超时
499，客户端主动断开连接。
http 中有关缓存的首部字段有哪些?http 的浏览器缓存机制。
1.Last-Modified 和 If-Modified-Since
在浏览器第一次请求某一个 URL 时，服务器端的返回状态会是 200，内容是你请求的 资源，同时有一个 Last-Modified 的属性标记此文件在服务期端最后被修改的时间，格式类 似这样:
Last-Modified: Fri, 12 May 2006 18:53:33 GMT
客户端第二次请求此 URL 时，浏览器会向服务器传送 If-Modified-Since 报头，询问 该时间之后文件是否有被修改过:
If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT
如果服务器端的资源没有变化，则自动返回 HTTP 304 状态码，内容为空，这样就 节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回 和第一次请求时类似，从而保证不向客户端重复发出资源，也保证当服务器有变化时，客 户端能够得到最新的资源。
2. ETag 和 If-None-Match
ETag 和 If-None-Match 的工作原理是在 HTTP Response 中添加 ETags 信息。当客户 端再次请求该资源时，将在 HTTP Request 中加入 If-None-Match 信息(也就是 ETags 的 值)。如果服务器验证资源的 ETags 没有改变(该资源的内容没有改变)，将返回一个 304 状态;否则，服务器将返回 200 状态，并返回该资源和新的 ETags。
a. 什么是ETag？
服务器会为每个资源分配对应的 ETag 值，根据资源的内容得到其值。当资源内容发 生改变时，其值也会改变。以下是服务器端返回的格式:
ETag: “50b1c1d4f775c61:df3”
客户端的查询更新格式是这样的:
If-None-Match: W/“50b1c1d4f775c61:df3”
如果 ETag 没改变，则返回状态 304，这也和 Last-Modified 一样。
扩展 2:既然有了 Last-Modified，为什么还要用 ETag 字段呢?
1.某些文件修改非常频繁，比如在秒以下的时间内进行修改(比方说 1s 内修改了 N 次)，If-Modified-Since 能检查到的粒度是秒级的，这种修改无法体现。
2.一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这 个时候我们并不希望客户端认为这个文件被修改了，而重新 GET;
3. Expires / Cache-Control(优先使用)
EXpires是在服务器时间的基础上，告诉浏览器缓存时间截止日期。
Expires: Sun, 16 Oct 2016 05:43:02 GMT 在此日期之前，客户端都会认为缓存是有效的
Cache-Control，是相对当前时间缓存的截止日期，
Cache-Control: max-age=315360000 这里声明的是一个相对的秒数，表示从现在起，315360000 秒内缓存都是有效的，这
样就避免了服务端和客户端时间不一致的问题。
但是 Cache-Control 是 HTTP1.1 才有的，不适用于 HTTP1.0，而 Expires 既适用于， HTTP1.0，也适用于 HTTP1.1，所以说在大多数情况下同时发送这两个头会是一个更好的 选择，当客户端两种头都能解析的时候，会优先使用 Cache-Control。
Https和Http的区别
1.了解数字证书：证书的颁发机构、证书的有效期、证书所有者公钥，主题(证书的所有者)，签名算法，指纹算法，指纹，数字签名。
2. 指纹算法是hash算法，通过hash证书的内容获得到的指纹(has值)， 签名是证书利用机构私钥对指纹加密得到的数字签名。（重点证书内容------>(指纹算法)------->指纹， 指纹-------->(签名算法，私钥(证书机构))--------->数字签名）
- https过程
a. 客户端请求服务器，连接到服务器443，发送支持的加密算法， 随机数RN-C。
b. 服务器返回（选择的加密算法， 随机数RN-S），CA数字证书。
c.客户端验证数字签名， （利用证书机构公钥解析数字签名，通过指纹算法计算数字证书内容，生成hash值，对比hash值（指纹）是否一致）。
d.认证通过后，利用服务器加密（随机数PMS等）发送给服务器。
e.服务器通过私钥解密，根据随机数和对称算法，生成对称密钥MS。
f.双方使用MS进行通讯。
g.使用对称密钥的原因；计算量相对非对象小。