计算机网络(网上资料整理)

参考：TCP四次挥手过程
参考:TCP的三次握手与四次挥手理解及面试题（很全面）
参考:DoS、DDos以及DRDoS攻击手段和防范措施
参考:[面试]cookie和session常见面试题
参考:老生常谈session、cookie的区别、安全性

1.TCP三次握手和四次挥手

1.三次握手

• 第一次握手
  建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。

• 第二次握手
  服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

• 第三次握手
  客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

2.四次挥手

连接的主动断开是可以发生在客户端，也同样可以发生在服务端。

• 第一次挥手
  A数据传输完毕需要断开连接，A的应用进程向其TCP发出连接释放报文段（FIN = 1,序号seq = u）,并停止再发送数据，主动关闭TCP连接，进入FIN-WAIT-1状态，等待B的确认。

• 第二次挥手
  B收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1,序号seq=v）,B进入CLOSE-WAIT关闭等待状态,此时的TCP处于半关闭状态，A到B的连接释放。而A收到B的确认后，进入FIN-WAIT-2状态，等待B发出的连接释放报文段。

• 第三次挥手
  当B数据传输完毕后，B发出连接释放报文段（FIN = 1，ACK = 1，序号seq = w,确认号ack=u+1）,B进入LAST-ACK（最后确认）状态，等待A 的最后确认。

• 第四次挥手
  A收到B的连接释放报文段后，对此发出确认报文段（ACK = 1，seq=u+1，ack=w+1）,A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，A才进入CLOSE状态。

3.为什么不能用两次握手进行连接？

3次握手完成两个重要的功能

• 既要双方做好发送数据的准备工作(双方都知道彼此已准备好)
• 也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

假设A发出的第一个连接请求报文段并没有丢失，而是在某些网络节点长时间滞留，后来某个时间又到达了B。本来这是一个早已失效的报文段，但B收到此报文段后一位是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。这浪费了资源。

4.为什么关闭的时候却是四次握手

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

5.为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态？

• 1.保证A发送的最后一个ACK报文段能够到达B，保证A、B正常进入CLOSED状态。
  这个ACK报文段有可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，B超时重传FIN+ACK报文段，A能2MSL时间内收到这个重传的FIN+ACK报文段，接着A重传一次确认，同时重启2MSL计数器，2MSL时间后A和B进入CLOSE状态，如果A在TIME-WAIT状态时接收到B的FIN+ACK报文段之后向B发出确认报文段，而不再确认B是否收到立即进入CLOSED状态，如若B并没有正常收到A 的确认报文段，则B无法正正常进入到CLOSED状态。

• 2.防止“已经失效的连接请求报文段”出现在本连接中。
  A在发送完最后一个ACK报文段并经过2MSL，会使本次连接持续时间内所有产生的报文段消失，保证在下一次新连接中不会出现旧连接遗留的请求报文段。

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

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

2.什么是DoS、DDoS、DRDoS攻击？如何防御？

1.DoS(拒绝服务攻击)

攻击者首先故意发起一个握手数据包，服务器收到以后将它放入等待队列，并返回确认。其次，攻击者不再发送第3个确认包，这样一来，服务器就会进行多次重传发送（Linux系统通过tcp_synack_retries配置重传次数），消耗了大量额外开销，以及等待队列被占用，甚至于等待队列被占满，最终导致服务器不能接收客户端的请求。这就是Syn-Flood攻击。

如何解决

• 缩短等待时间
  尽早删除在等待队列中等待非法请求数据包；

• 第一次握手报文不放入等待队列
  我们将一个32位的无符号整数作为第二次握手的Seq返回给客户端，该整数通过将用户请求的参数（包括请求的地址、端口等），加上服务器的一个序列号等做了一次运算得到。如果是正常用户，它在收到这个整数之后加1作为ACK返回给服务器，服务器在拿到数据后，对这个ACK减1再进行逆运算得到各个参数，最后发出去的数据进行比对，如果完全一致，说明是一个有效的响应，存放到相应的数据结构，反之则不是。通过该方法，非法请求就不能占用系统资源了。

2.DDoS(分布式拒绝服务)

攻击者首先控制大量肉鸡，然后向目标服务器发送海量请求，导致目标服务器不可用。

解决

• 设置访问频率阈值
  当某个IP单位时间内访问次数超过这个阈值就拒绝；对于某个服务，如果瞬时请求过大，选择直接拒绝保证其他服务的正常工作；这种方式可能导致正常用户也无法使用。

• 验证码
  为了防止暴露方式带来的误伤正常用户，目前服务商在收到大量请求时，会向"用户"发送验证码，如果是真实用户则会输入验证码，而是肉鸡的话，则不会，通过该方法则分辨出真实用户和肉鸡。

3.DRDoS(分布式反射拒绝服务)

攻击者将不是将请求直接发送给被攻击者，而是发送给一个第三方，通过第三方中转到被攻击者，这就是"Reflection"的体现。它的流程具体如下：攻击者将请求包的源IP篡改成要被攻击者的IP，目标IP是第三方IP，那么第三方的恢复报文的目标IP就变成被攻击者的IP，这样一来，被攻击者就会收到大量请求导致服务不可用。

需要注意的是：1. 攻击者往往选择的是基于UDP协议的系统，因为UDP协议是不可靠的，能够伪造源IP； 2. 攻击者往往会选择那些响应包大于请求包的服务。基于此，一般被被攻击的服务包括DNS服务、Memcached服务等。

解决

• 扩大服务器的宽带
• 尽可能选择TCP协议
• 对于一些被放大的返回包直接进行丢弃。

3.你怎么理解http协议

1.HTTP协议的特点

• HTTP协议是无状态的
  就是说每次HTTP请求都是独立的，任何两个请求之间没有什么必然的联系。但是在实际应用当中并不是完全这样的，引入了Cookie和Session机制来关联请求。

• 基于请求和响应：基本的特性，由客户端发起请求，服务端响应

• 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

• 基于TCP协议
  HTTP协议目的是规定客户端和服务端数据传输的格式和数据交互行为，并不负责数据传输的细节。底层是基于TCP实现的。现在使用的版本当中是默认持久连接的，也就是多次HTTP请求使用一个TCP连接。

2.HTTP协议工作流程

• 地址解析
  HTTP协议是通过标准URL来请求指定的服务器中指定服务的

• 封装HTTP 请求
  这一步把上面写的 URL 以及本机的一些信息封装成一个 HTTP 请求数据包

• 封装 TCP 包，建立 TCP 连接
  第三步就是封装 TCP 包 , 建立 TCP 连接 , 也就是常说的"三次握手" .

• 客户端发送请求命令
  客户端发送 HTTP 请求到服务端与请求相关的信息都会包含在请求头和请求体中发送给服务器端 .

• 服务端响应
  服务器端在收到请求之后 , 根据客户端的请求发送给客户端相应的信息 , 相关的响应信息都会放在响应头和响应体中 .

• 关闭连接
  如果客户端的请求的头部信息中有 Connection-alive , 那么客户端在响应完这个请求之后不会关闭连接 , 知道客户端的所有请求都响应完毕 , 才会关闭连接 , 这样大大节省了带宽和 IO 资源 .

3.HTTP报文组成

• 请求行
  请求的第一行是请求行 , 里面有请求方法 , URL , 协议版本等

• 请求头
  每个头域都由一个头域名 , 冒号和值域组成

• 请求正文
  也叫请求数据 , 在使用post请求表单数据的时候 , 这些表单数据就会被放在 HTTP 请求的请求正文中 , 以加密的形式向服务器传输 .

4.HTTP请求方法

5.HTTP的响应状态码

• 200
  OK

• 301 ： Moved Permanently
  代表永久性定向。该状态码表示请求的资源已经被分配了新的URL，以后应该使用资源现在指定的URL。

• 302：Found
  代表临时重定向。该状态码表示请求的资源已经被分配了新的URL，但是和301的区别是302代表的不是永久性的移动，只是临时的。就是说这个URL还可能会发生改变。

• 400：Bad Request
  400表示请求报文中存在语法错误。需要修改后再次发送。

• 401：Unauthorized
  该状态码表示发送的请求需要有通过HTTP认证的认证信息。

• 403：Forbidden
  表明请求访问的资源被拒绝了。没有获得服务器的访问权限，IP被禁止等。

• 404：Not Found
  表明请求的资源在服务器上找不到。当然也可以在服务器拒绝请求且不想说明理由时使用。

• 500：Internal Server Error
  表明服务器端在执行请求时发生了错误，很有可能是服务端程序的Bug或者临时故障。

• 503：Service Unavailable
  表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入Retry-After字段再返回给客户端。

• 504：Getaway Timeout
  网关超时，是代理服务器等待应用服务器响应时的超时

6.Get与Post区别

4.Https

经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

1.特点

• 内容加密：采用混合加密技术，中间者无法直接查看明文内容
• 验证身份：通过证书认证客户端访问的是自己的服务器
• 保护数据完整性：防止传输的内容被中间人冒充或者篡改

2.解决内容可能被窃听的问题

加密。

3.解决报文可能遭篡改问题

网络传输过程中需要经过很多中间节点，虽然数据无法被解密，但可能被篡改，那如何校验数据的完整性呢?----校验数字签名。

数字签名有两种功效：

• 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
• 数字签名能确定消息的完整性,证明数据是否未被篡改过。

数字签名技术就是对“非对称密钥加解密”和“数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用 HASH 函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

4.解决通信方身份可能被伪装的问题

使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。
接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

5.Cookie和Session

1.Cookie和Session原理概述

cookie采用的是客户端的会话状态的一种储存机制。它是服务器在本地机器上存储的小段文本或者是内存中的一段数据，并随每一个请求发送至同一个服务器。

session是一种服务器端的信息管理机制，它把这些文件信息以文件的形式存放在服务器上。当客户端向服务器发出请求时，要求服务器端产生一个session时，服务器端会先检查一下，客户端的cookie里面有没有session_id，是否过期。如果有这样的session_id的话，服务器端会根据cookie里的session_id把服务器的session检索出来。如果没有这样的session_id的话，服务器端会重新建立一个。

2.Cookie和Session区别

• 存在的位置
  cookie 存在于客户端，临时文件夹中；
  session存在于服务器的内存中，一个session域对象为一个用户浏览器服务

• 安全性
  cookie是以明文的方式存放在客户端的，安全性低，可以通过一个加密算法进行加密后存放；
  session存放于服务器的内存中，所以安全性好

• 网络传输量
  cookie会传递消息给服务器； session本身存放于服务器，不会有传送流量

• 生命周期

  • cookie的生命周期是累计的，从创建时，就开始计时，到达时间后，cookie生命周期结束；
  • session的生命周期是间隔的，从创建时，开始计时，没有访问session，那么session生命周期被销毁。
  • 但是，如果在这个时间内访问过session，那么，将重新计算session的生命周期。
  • 关机会造成session生命周期的结束，但是对cookie没有影响

• 访问范围
  cookie为多个用户浏览器共享；
  session为一个用户浏览器独享

3.如果用户把cookie禁止掉，是不是session也不能用了

禁止掉cookie后，session当然可以用，不过通过其他的方式来获得这个sessionid，比如，可以跟在url的后面，或者以表单的形势提交到服务器端。从而使服务器端了解客户端的状态。

4.为什么说session 比cookie更安全

Cookie存放在浏览器内存或者文件方式硬盘空间上，那么要攻破Cookie只需要拿到Cookie的内容进行发送即可。

• session的sessionID是放在cookie里，要想功破session的话，第一要功破cookie。
• 功破cookie后，要得到 sessionID,sessionID是要有人登录，或者启动session_start才会有
  • 不知道什么时候会有人登录。
  • sessionID是加密的，第二次session_start的时候，前一次的sessionID就没有用了，session过期时sessionid也会失效，想在短时间内功破加了密的 sessionID很难。session是针对某一次通信而言，会话结束session也就随着消失了。