Skip to content

Latest commit

 

History

History
142 lines (106 loc) · 9.08 KB

note.md

File metadata and controls

142 lines (106 loc) · 9.08 KB

前端和后端是如何通信的

  • 前端： 客户端
  • 后端： 服务器端
  • 全栈： 同时实现两端程序编写和通信
    当我们在浏览器地址栏中输入一个URL地址，到最后看到页面，中间都经历了哪些事情？
    //https://segmentfault.com/a/1190000006879700

当我们在浏览器地址栏中输入一个URL地址，到最后看到页面，中间都经历了哪些事情？

总体来说分为以下几个过程:

  • 1.DNS解析

  • 2.TCP连接

  • 3.发送HTTP请求

  • 4.服务器处理请求并返回HTTP报文

  • 5.浏览器解析渲染页面

  • 6.连接结束

DNS解析

DNS优化

  • 了解了DNS的过程，可以为我们带来哪些？上文中请求到google的IP地址时，经历了8个步骤，这个过程中存在多个请求(同时存在UDP和TCP请求，为什么有两种请求方式，请自行查找)。如果每次都经过这么多步骤，是否太耗时间？如何减少该过程的步骤呢？那就是DNS缓存。

DNS缓存

  • DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。
  • 在你的chrome浏览器中输入:chrome://dns/，你可以看到chrome浏览器的DNS缓存。
  • 系统缓存主要存在/etc/hosts(Linux系统)中

DNS负载均衡

  • 不知道大家有没有思考过一个问题: DNS返回的IP地址是否每次都一样？如果每次都一样是否说明你请求的资源都位于同一台机器上面，那么这台机器需要多高的性能和储存才能满足亿万请求呢？其实真实的互联网世界背后存在成千上百台服务器，大型的网站甚至更多。但是在用户的眼中，它需要的只是处理他的请求，哪台机器处理请求并不重要。DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡，又叫做DNS重定向。大家耳熟能详的CDN(Content Delivery Network)就是利用DNS的重定向技术，DNS服务器会返回一个跟用户最接近的点的IP地址给用户，CDN节点的服务器负责响应用户的请求，提供所需的内容。在这里打个免费的广告，我平时使用的比较多的是七牛云的CDN(免费)储存图片，作为我个人博客的图床使用。

TCP连接

  • HTTP协议是使用TCP作为其传输层协议的，当TCP出现瓶颈时，HTTP也会受到影响。

HTTPS协议

  • HTTP报文是包裹在TCP报文中发送的，服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中存在一定的风险，HTTP报文是明文，如果中间被截取的话会存在一些信息泄露的风险。那么在进入TCP报文之前对HTTP做一次加密就可以解决这个问题了。HTTPS协议的本质就是HTTP + SSL(or TLS)。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。

HTTPS过程

  • HTTPS在传输数据之前需要客户端与服务器进行一个握手(TLS/SSL握手)，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL使用了非对称加密，对称加密以及hash等。具体过程请参考经典的阮一峰先生的博客TLS/SSL握手过程。 HTTPS相比于HTTP，虽然提供了安全保证，但是势必会带来一些时间上的损耗，如握手和加密等过程，是否使用HTTPS需要根据具体情况在安全和性能方面做出权衡。

HTTP请求

  • 其实这部分又可以称为前端工程师眼中的HTTP，它主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。HTTP请求报文是由三部分组成: 请求行, 请求报头和请求正文。

请求行

    格式如下:
    Method Request-URL HTTP-Version CRLF

    eg: GET index.html HTTP/1.1
    常用的方法有: GET, POST, PUT, DELETE, OPTIONS, HEAD。

请求报头

  • 请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。 PS: 客户端不一定特指浏览器，有时候也可使用Linux下的CURL命令以及HTTP客户端测试工具等。 常见的请求报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。

请求正文

  • 当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求包头中有一些与请求正文相关的信息，例如: 现在的Web应用通常采用Rest架构，请求的数据格式一般为json。这时就需要设置Content-Type: application/json。

服务器处理请求并返回HTTP报文

  • 自然而然这部分对应的就是后端工程师眼中的HTTP。后端从在固定的端口接收到TCP报文开始，这一部分对应于编程语言中的socket。它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。这一部分工作一般是由Web服务器去进行，我使用过的Web服务器有Tomcat, Jetty和Netty等等。HTTP响应报文也是由三部分组成: 状态码, 响应报头和响应报文。

状态码

  • 1xx：指示信息–表示请求已接收，继续处理。
  • 2xx：成功–表示请求已被成功接收、理解、接受。
  • 3xx：重定向–要完成请求必须进行更进一步的操作。
  • 4xx：客户端错误–请求有语法错误或请求无法实现。
  • 5xx：服务器端错误–服务器未能实现合法的请求。
  • 平时遇到比较常见的状态码有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500(分别表示什么请自行查找)。
  • 状态码流程

301和302有什么区别？HTTP缓存？

HTTP 报文

1、起始行 请求起始行 响应起始行

2、首部（头） 请求头：内置请求头/自定义请求头 响应头：内置响应头/自定义响应头 通用头；请求和响应都有的

3、主体 请求主体 响应主体

请求xxx都是客户端设置的信息,服务器端获取这些信息 响应xxx都是服务器端设置的信息，客户端用来接收

总结 客户端传递给服务器端数据 1、URL问好传递参数 2、设置请求头 3、设置请求主体

服务器端返回给客户端内容 1、设置响应头 2、设置响应主体 。。。

URL、URI、URN

URI: 统一资源标识符 URL: 统一资源路径地址 URN: 统一资源名称 URI = URL + URN

about Server

  • 一台服务器的端口号取值范围：0-65535
  • http: 默认端口80
  • https: 默认端口443
  • ftp: 默认端口21
  • 以上三种，如果端口号被占用，我们则不能使用了：所以服务骑上一般是禁止安装其他程序的：
  • 消除ajax请求中GET方式缓存(在请求URL的末尾追加一个随机数)