计算机网络

三次握手
三次握手的过程

为了保证数据能到达目标，TCP采用三次握手策略：

1. 发送端首先发送一个带SYN（synchronize）标志的数据包给接收方【第一次的seq序列号是随机产生的，这样是为了网络安全，如果不是随机产生初始序列号，黑客将会以很容易的方式获取到你与其他主机之间的初始化序列号，并且伪造序列号进行攻击】
2. 接收端收到后，回传一个带有SYN/ACK（acknowledgement）标志的数据包以示传达确认信息【SYN 是为了告诉发送端，发送方到接收方的通道没问题；ACK 用来验证接收方到发送方的通道没问题】

3. 最后，发送端再回传一个带ACK标志的数据包，代表握手结束若在握手某个过程中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的数据包

   为什么要三次握手？
   三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的

4. 第一次握手，发送端：什么都确认不了；接收端：对方发送正常，自己接受正常
5. 第二次握手，发送端：对方发送，接受正常，自己发送，接受正常 ；接收端：对方发送正常，自己接受正常
6. 第三次握手，发送端：对方发送，接受正常，自己发送，接受正常；接收端：对方发送，接受正常，自己发送，接受正常
   两次握手不行吗？为什么TCP客户端还要发送一次确认呢？
   主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。经典场景：客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了。
7. 由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。
8. 此时此前滞留的那一次请求连接，网络通畅了到达服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
9. 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
   为什么三次握手，返回时，ack 值是 seq 加 1（ack = x+1）
   ● 假设对方接收到数据，比如sequence number = 1000，TCP Payload = 1000，数据第一个字节编号为1000，最后一个为1999，回应一个确认报文，确认号为2000，意味着编号2000前的字节接收完成，准备接收编号为2000及更多的数据
   ● 确认收到的序列，并且告诉发送端下一次发送的序列号从哪里开始（便于接收方对数据排序，便于选择重传）
   TCP三次握手中，最后一次回复丢失，会发生什么？
   ● 如果最后一次ACK在网络中丢失，那么Server端（服务端）该TCP连接的状态仍为SYN_RECV，并且根据 TCP的超时重传机制依次等待3秒、6秒、12秒后重新发送 SYN+ACK 包，以便 Client（客户端）重新发送ACK包
   ● 如果重发指定次数后，仍然未收到ACK应答，那么一段时间后，Server（服务端）自动关闭这个连接
   ● 但是Client（客户端）认为这个连接已经建立，如果Client（客户端）端向Server（服务端）发送数据，Server端（服务端）将以RST包（Reset，标示复位，用于异常的关闭连接）响应，此时，客户端知道第三次握手失败
   SYN洪泛攻击(SYN Flood，半开放攻击)，怎么解决？
   ● 什么是SYN洪范泛攻击？
   SYN Flood利用TCP协议缺陷，发送大量伪造的TCP连接请求，常用假冒的IP或IP号段发来海量的请求连接的第一个握手包（SYN包），被攻击服务器回应第二个握手包（SYN+ACK包），因为对方是假冒IP，对方永远收不到包且不会回应第三个握手包。导致被攻击服务器保持大量SYN_RECV状态的“半连接”，并且会重试默认5次回应第二个握手包，大量随机的恶意syn占满了未完成连接队列，导致正常合法的syn排不上队列，让正常的业务请求连接不进来。【服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击】
   ● 如何检测 SYN 攻击？
   当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击【在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击】
   ● 怎么解决？
   SYN攻击不能完全被阻止，除非将TCP协议重新设计。我们所做的是尽可能的减轻SYN攻击的危害，
10. 缩短超时（SYN Timeout）时间
11. 增加最大半连接数
12. 过滤网关防护
13. SYN cookies技术：
    a. 当服务器接受到 SYN 报文段时，不直接为该 TCP 分配资源，而只是打开一个半开的套接字。接着会使用 SYN 报文段的源 Id，目的 Id，端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie，并把 cookie 作为序列号响应给客户端。
    b. 如果客户端是正常建立连接，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源 Id，目的 Id，端口号以及秘密函数计算出一个结果，如果结果的值 + 1 等于确认字段的值，则证明是刚刚请求连接的客户端，这时候才为该 TCP 分配资源
    四次挥手
    四次挥手的过程

● 主动断开方（客户端/服务端）-发送一个 FIN，用来关闭主动断开方（客户端/服务端）到被动断开方（客户端/服务端）的数据传送
● 被动断开方（客户端/服务端）-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
● 被动断开方（客户端/服务端）-关闭与主动断开方（客户端/服务端）的连接，发送一个FIN给主动断开方（客户端/服务端）
● 主动断开方（客户端/服务端）-发回 ACK 报文确认，并将确认序号设置为收到序号加1
为什么连接的时候是三次握手，关闭的时候却是四次握手？
● 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
● 关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了,所以服务器可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接。因此，服务器ACK和FIN一般都会分开发送，从而导致多了一次
为什么TCP挥手每两次中间有一个 FIN-WAIT2等待时间？
主动关闭的一端调用完close以后（即发FIN给被动关闭的一端， 并且收到其对FIN的确认ACK）则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因，导致主动关闭的一端不能收到被动关闭的一端发来的FIN（防止对端不发送关闭连接的FIN包给本端），这个时候就需要FIN_WAIT_2定时器， 如果在该定时器超时的时候，还是没收到被动关闭一端发来的FIN，那么直接释放这个链接，进入CLOSE状态
为什么客户端最后还要等待2MSL？为什么还有个TIME-WAIT的时间等待？
● 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，服务器已经发送了FIN+ACK报文，请求断开，客户端却没有回应，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
● 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样新的连接中不会出现旧连接的请求报文。
● 2MSL，最大报文生存时间，一个MSL 30 秒，2MSL = 60s
客户端 TIME-WAIT 状态过多会产生什么后果？怎样处理？
● 作为服务器，短时间内关闭了大量的Client连接，就会造成服务器上出现大量的TIME_WAIT连接，占据大量的tuple /tApl/ ，严重消耗着服务器的资源，此时部分客户端就会显示连接不上
● 作为客户端，短时间内大量的短连接，会大量消耗的Client机器的端口，毕竟端口只有65535个，端口被耗尽了，后续就无法在发起新的连接了
● 在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上
a. 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了
b. 短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接
● 解决方法：
a. 用负载均衡来抗这些高并发的短请求；
b. 服务器可以设置 SO_REUSEADDR 套接字选项来避免 TIME_WAIT状态，TIME_WAIT 状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的
c. 强制关闭，发送 RST 包越过TIMEWAIT状态，直接进入CLOSED状态
服务器出现了大量 CLOSE_WAIT 状态如何解决？
大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭连接，而我方忙于读或写没有及时关闭连接，需要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。
服务端会有一个TIME_WAIT状态吗？如果是服务端主动断开连接呢？
● 发起链接的主动方基本都是客户端，但是断开连接的主动方服务器和客户端都可以充当，也就是说，只要是主动断开连接的，就会有 TIME_WAIT状态
● 四次挥手是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发
● 由于TCP连接时全双工的，因此，每个方向的数据传输通道都必须要单独进行关闭
https

开发安全
SQL注入
● 使用预编译处理输入参数：要防御 SQL 注入，用户的输入就不能直接嵌套在 SQL 语句当中。使用参数化的语句，用户的输入就被限制于一个参数当中， 比如用prepareStatement
● 输入验证：检查用户输入的合法性，以确保输入的内容为正常的数据。数据检查应当在客户端和服务器端都执行，之所以要执行服务器端验证，是因为客户端的校验往往只是减轻服务器的压力和提高对用户的友好度，攻击者完全有可能通过抓包修改参数或者是获得网页的源代码后，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器等等手段绕过客户端的校验。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。但是这些方法很容易出现由于过滤不严导致恶意攻击者可能绕过这些过滤的现象，需要慎重使用。
● 错误消息处理：防范 SQL 注入，还要避免出现一些详细的错误消息，恶意攻击者往往会利用这些报错信息来判断后台 SQL 的拼接形式，甚至是直接利用这些报错注入将数据库中的数据通过报错信息显示出来。
● 加密处理：将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入 SQL 命令。
CSRF攻击

● 有哪些CSRF 防御常规思路？

1. 验证 HTTP Referer 字段， 根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。只需要验证referer
2. 在请求地址中添加 token 并验证，可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。 这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对，但这种方法的难点在于如何把 token 以参数的形式加入请求。
3. 在 HTTP 头中自定义属性并验证
   XSS攻击
   可执行脚本放到输入框中进行提交。
   ● XSS 攻击的防御？
   XSS攻击其实就是代码的注入。用户的输入被编译成恶意的程序代码。所以，为了防范这一类代码的注入，需要确保用户输入的安全性。对于攻击验证，我们可以采用以下两种措施：
4. 编码，就是转义用户的输入，把用户的输入解读为数据而不是代码
5. 校验，对用户的输入及请求都进行过滤检查，如对特殊字符进行过滤，设置输入域的匹配规则等。
   tcp的滑动窗口协议
   窗口大小由哪一方决定？
   TCP 头里有一个字段叫 Window，也就是窗口大小。这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。所以，通常窗口的大小是由接收方的窗口大小来决定的。发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。
   发送方的滑动窗口
   我们先来看看发送方的窗口，下图就是发送方缓存的数据，根据处理的情况分成四个部分，其中深蓝色方框是发送窗口，紫色方框是可用窗口：

接收窗口和发送窗口的大小是相等的吗？
并不是完全相等，接收窗口的大小是约等于发送窗口的大小的。
因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。
TCP 粘包/拆包的原因及解决方法
TCP 是以流的方式来处理数据，一个完整的包可能会被 TCP 拆分成多个包进行发送，也可能把小的封装成一个大的数据包发送。
● TCP 粘包/分包的原因：
TCP 是一个面向「流」的协议，所谓流就是没有界限的一长串二进制数据。TCP 作为传输层协议并不了解上层业务数据的具体含义，它会根据TCP缓冲区的实际情况进行数据包的划分，所以在业务上认为是一个完整的包，可能会被 TCP 拆分成多个包进行发送，也有可能把多个小的包封装成一个大的数据包发送，这就会出现粘包拆包的问题。
例如，TCP缓冲区是1024个字节大小，如果应用一次请求发送的数据量比较小，没达到缓冲区大小，TCP则会将多个请求合并为同一个请求进行发送，站在业务上来看这就是「粘包」;
如果应用一次请求发送的数据量比较大，超过了缓冲区大小，TCP就会将其拆分为多次发送，这就是「拆包」，也就是将一个大的包拆分为多个小包进行发送。
● 解决方法：
(1)发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。如下图，在每个包前面加上包的实际长度。

(2)发送端将每个数据包封装为固定长度(不够的可以通过补0填充)，这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。

(3)可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。如下图，在每个包的后面加上特殊字符：/

回答：
TCP 是一个面向「流」的协议，所谓流就是没有界限的一长串二进制数据。在实际的传输过程中，TCP 会根据网络情况将数据包进行拆分或者拼装，如果业务没有定义一个明确的界限规则，在应用层的业务上就会出现粘包拆包的现象。
针对 TCP 粘包拆包的现象，常见的解决思路如下：
(1)发送端给每个数据包添加包首部。
(2)发送端将每个数据包封装为固定长度。
(3)可以在数据包之间设置边界。
tcp流量控制如何处理的
主要通过客户端的发送缓存区和服务端的服务缓存区，如果接收缓存区满了，就告诉客户端不能继续发送了，为了控制发送端的速率，接收端会告知自己的接收窗口(空闲部分)，会通过客户端的滑动窗口来控制。这个时候发送方其实是有好几种发送的数据包的状态，已发送已确认，已发送未确认，未发送能接收，未发送，顺序执行。
TCP和UDP的区别

1. TCP是面向连接的协议，UDP是无连接协议。TCP 发送数据前使用三次握手建立连接，UDP 发送数据前不需要建立连接。
2. TCP 可靠，UDP 不可靠。TCP 丢包会自动重传，UDP 不会(任何必需的可靠性必须由应用层来提供)。 TCP 可靠性由三个机制保证：1. 序号（TCP 报文的序号）2. 确认（ACK 机制）3. 重传（超时或者冗余的 ACK）
3. TCP 有序，UDP 无序。消息在传输过程中可能会乱序，后发送的消息可能会先到达，TCP 会对其进行重新排序，UDP 不会。
4. TCP 无界，UDP 有界。TCP 通过字节流传输，UDP 中每一个包都是单独的。
5. TCP 有流量控制（拥塞控制），UDP 没有。TCP 协议的流量控制是基于滑窗协议实现的。 拥塞控制和流量控制不同，流量控制是点对点的通信量抑制，抑制发送端发送速率，使得接收端来得及接收。
6. TCP 传输慢，UDP 传输快。因为 TCP 需要建立连接、保证可靠性和有序性，所以比较耗时。 这就是为什么视频流、广播电视、在线多媒体游戏等选择使用 UDP。
7. TCP 是重量级的，UDP 是轻量级的。TCP 要建立连接、保证可靠性和有序性，就会传输更多的信息，如 TCP 的包头比较大。
   select、poll、epoll的区别
   select poll epoll
   底层数据结构 数组存储文件描述符 链表存储文件描述符 红黑树存储监控的文件描述符，双链表存储就绪的文件描述符
   如何从fd数据中获取就绪的fd 遍历fd_set 遍历链表 回调
   时间复杂度 获得就绪的文件描述符需要遍历fd数组，O(n) 获得就绪的文件描述符需要遍历fd链表，O(n) 当有就绪事件时，系统注册的回调函数就会被调用，将就绪的fd放入到就绪链表中。O(1)
   FD数据拷贝 每次调用select，需要将fd数据从用户空间拷贝到内核空间 每次调用poll，需要将fd数据从用户空间拷贝到内核空间 使用内存映射(mmap)，不需要从用户空间频繁拷贝fd数据到内核空间
   最大连接数 有限制，一般为1024 无限制 无限制
   常见http状态码
   ● 1XX：消息状态码。
   ● 2XX：成功状态码。
   ● 3XX：重定向状态码。
   ● 4XX：客户端错误状态码。
   ● 5XX：服务端错误状态码。
   常见状态码：
   ● 200：OK 请求成功。一般用于 GET 与 POST 请求。
   ● 201：Created 已创建。成功请求并创建了新的资源。
   ● 301：Moved Permanently 永久移动。请求的资源已被永久的移动到新 URI，返回信息会包括新的 URI，浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替。
   ● 302：Found 临时移动，与 301 类似。但资源只是临时被移动。客户端应继续使用原有URI。
   ● 304：Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。
   ● 400：Bad Request 客户端请求的语法错误，服务器无法理解。
   ● 401：Unauthorized 请求要求用户的身份认证。
   ● 403：Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求。
   ● 404：Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面。
   ● 414：Request-URI Too Large 请求的 URI 过长（URI通常为网址），服务器无法处理。
   ● 500：Internal Server Error 服务器内部错误，无法完成请求。
   ● 502：Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应。
   ● 503：Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中。
   ● 504：Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求。