计算机网络必须知道的点

计算机网络必须知道的点

1、HTTP协议：

• HTTP构建于TCP/IP协议之上，默认端口号是80
• HTTP是无连接无状态的
• HTTP 请求分为三个部分：状态行、请求头、消息主体。

HTTP定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。

一个URL地址，它用于描述一个网络上的资源，而 HTTP 中的GET，POST，PUT，DELETE就对应着对这个资源的查，增，改，删4个操作。

1. GET获取信息，应该是安全的和幂等的。
   • 安全的：该操作用于获取信息，而非修改信息。
   • 幂等的：对同一URL的多个请求应该返回同样的结果。
2. POST表示可能修改变服务器上的资源的请求。
3. 注意：
   • GET 可提交的数据量受到URL长度的限制，HTTP 协议规范没有对 URL 长度进行限制。这个限制是特定的浏览器及服务器对它的限制。
   • 理论上讲，POST 是没有大小限制的，HTTP 协议规范也没有进行大小限制，出于安全考虑，服务器软件在实现时会做一定限制。
   • GET 和 POST 数据内容是一模一样的，只是位置不同，一个在URL里，一个在 HTTP 包的包体里。

2、常见的响应状态码：

• 200 OK 客户端请求成功。
• 301 Moved Permanently 请求永久重定向。
• 302 Moved Temporarily 请求临时重定向。
• 304 Not Modified 文件未修改，可以直接使用缓存的文件。
• 400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。
• 401 Unauthorized 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用。
• 403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因。
• 404 Not Found 请求的资源不存在，例如，输入了错误的URL。
• 500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。
• 503 Service Unavailable 服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常。

3、持久连接 Keep-Alive ：

• HTTP Keep-Alive 简单说就是保持当前的TCP连接，避免了重新建立连接。
• HTTP 长连接不可能一直保持，例如 Keep-Alive: timeout=5, max=100，表示这个TCP通道可以保持5秒，max=100，表示这个长连接最多接收100次请求就断开。
• HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在 HTTP1.1 版本中也如此。唯一能保证的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于 Keep-Alive 的保持连接特性，否则会有意想不到的后果。
• 使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1. 判断传输数据是否达到了Content-Length 指示的大小；2. 动态生成的文件没有 Content-Length ，它是分块传输（chunked），这时候就要根据 chunked 编码来判断，chunked 编码的数据在最后有一个空 chunked 块，表明本次传输数据结束

4、会话跟踪：

1. 什么是会话？

   客户端打开与服务器的连接发出请求到服务器响应客户端请求的全过程称之为会话。

2. 什么是会话跟踪？

   会话跟踪指的是对同一个用户对服务器的连续的请求和接受响应的监视。

3. 为什么需要会话跟踪？

   浏览器与服务器之间的通信是通过HTTP协议进行通信的，而HTTP协议是”无状态”的协议，它不能保存客户的信息，即一次响应完成之后连接就断开了，下一次的请求需要重新连接，这样就需要判断是否是同一个用户，所以才有会话跟踪技术来实现这种要求。

4、会话跟踪常用方法：

• URL重写：

  URL重写的技术就是在URL结尾添加一个附加数据以标识该会话,把会话ID通过URL的信息传递过去，以便在服务器端进行识别不同的用户。

• 隐藏表单域：

  将会话ID添加到HTML表单元素中提交到服务器，此表单元素并不在客户端显示。

• cookie：

  Cookie是Web服务器发送给客户端的一小段信息，客户端请求时可以读取该信息发送到服务器端，进而进行用户的识别。对于客户端的每次请求，服务器都会将Cookie发送到客户端,在客户端可以进行保存,以便下次使用。

• session：

  在服务器端会创建一个session对象，产生一个sessionID来标识这个session对象，然后将这个sessionID放入到Cookie中发送到客户端，下一次访问时，sessionID会发送到服务器，在服务器端进行识别不同的用户。

注意：Session的实现依赖于Cookie，如果Cookie被禁用，那么session也将失效。

5、跨站攻击：

1、CSRF：跨站请求伪造。

CSRF(XSRF) 顾名思义，是伪造请求，冒充用户在站内的正常操作。

1. 如何防范CSRF攻击：

• 关键操作只接受POST请求。

• 验证码。

• 检测 Referer。

  Referer Check 一般用于监控 CSRF 攻击的发生，而不用来抵御攻击。

• token。

  目前主流的做法是使用 Token 抵御 CSRF 攻击。

  CSRF攻击要成功的条件在于攻击者能够预测所有的参数从而构造出合法的请求。所以根据不可预测性原则，我们可以对参数进行加密从而防止CSRF攻击。

  另一个更通用的做法是保持原有参数不变，另外添加一个参数Token，其值是随机的。这样攻击者因为不知道Token而无法构造出合法的请求进行攻击。

2. token的使用原则：

• Token 要足够随机————只有这样才算不可预测。
• Token 是一次性的，即每次请求成功后要更新Token————这样可以增加攻击难度，增加预测难度。
• Token 要注意保密性————敏感操作使用 post，防止 Token 出现在 URL 中。

注意：过滤用户输入的内容不能阻挡 csrf，我们需要做的是过滤请求的来源。

2、XSS：跨站脚本攻击。

XSS 全称“跨站脚本”，是注入攻击的一种。

特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。

XSS 是实现 CSRF 的诸多途径中的一条，但绝对不是唯一的一条。一般习惯上把通过 XSS 来实现的 CSRF 称为 XSRF。

如何防御 XSS 攻击？

理论上，所有可输入的地方没有对输入数据进行处理的话，都会存在XSS漏洞，漏洞的危害取决于攻击代码的威力，攻击代码也不局限于script。防御 XSS 攻击最简单直接的方法，就是过滤用户的输入。

运行预期之外的脚本带来的后果有很多中，可能只是简单的恶作剧——一个关不掉的窗口：

  while (true) {
      alert("你关不掉我~");
  }