Web十分简单，至少用起来是这样！其实构成万维网的系统相当复杂，大多数情况下我们可以简单的说web就是相互链接的文档的集合。在学习web的工程中，我们经常会提到web服务器、动态和静态内容、HTML、JSON与其他内容，你是否对它们如何进行协调工作有一定的好奇，这篇文章带你了解一下Web 的工作方式及原理。
大家所看到的Web网站通常由大量的系统构成，这些系统协通过工作，营造出单个系统的假象。如果某个系统出现问题的话，会直接导致Web彻底崩溃。
计算机需要找到IP地址，通常我们在访问的时候输入的是域名，需要将域名转为ip地址。通常使用的是DNS域名解析服务[它作为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网]。
所有连接在互联网上的计算机至少配置了一个DNS服务器，在浏览器准备连接到网站之前，必须等待联系ISP的DNS服务器，以获取正确的IP地址。一般域名托管在不错的云服务提供商，速度都挺快的。
DNS 优化
DNS负载均衡
就以上图为例，上图是ping www.baidu.com 得到的ip地址，首先在本地域名服务器中查询IP地址，如果没有找到的情况下，本地域名服务器会向根域名服务器发送一个请求，如果根域名服务器也不存在该域名时，本地域名会向com顶级域名服务器发送一个请求，依次类推下去。直到最后本地域名服务器得到baidu的IP地址并把它缓存到本地，供下次查询使用。从上述过程中，可以看出网址的解析是一个从右向左的过程: com -> baidu.com ->www.google.com。
那么大家都会问根域名服务器呢？其实真正的域名服务器是www.baidu.com. ，从上图就可以看出来，这个.对应的就是根域名服务器，默认情况下所有的网址的最后一位都是.，既然是默认情况下，为了方便用户，通常都会省略，浏览器在请求DNS的时候会自动加上，所有网址真正的解析过程为: . -> .com -> baidu.com. -> www.baidu.com.。
TCP网络协议是当今互联网所用的两个关键协议之一，另一个是UDP。简单来说，TCP是可靠的，UDP不是。
TCP 使用IP来传送数据包及对其进行路由，但也保证了传送过程和数据包的顺序。从开发者的角度来说一旦建立 了TCP连接，从一端发送的数据包就保证能到达另一端。为了实现这一点，TCP采用了基于传送数据量的序列码（sequence number）的概念。这部分信息会被路由器忽略，只有连接两端的计算机才会用到。这样，我们就能保持状态，只需在两个传送端点上而非所有的路由器上都保持。采用了序列码，系统就能判定是否数据丢失。
我不知道把HTTPS放在这个部分是否合适。HTTPS报文包裹在TCP报文中发送的，服务器端收到TCP报文时会解包提取出HTTP报文。但是这个过程中有一定的风险，HTTP报文是明文，如果中间被截取的话就存在一些信息泄露的风险。那么在进入TCP报文之前做一次加密就可以解决这个问题。HTTPS协议的本质就是HTTP+SSL（或TLS）。在HTTP报文进入TCP报文之前，先使用SSL对HTTP报文进行加密。从网络的层级结构看它位于HTTP协议与TCP协议之间。
HTTPS在运输数据之前需要客户端与服务器进行一个握手（TLS/SSL握手），在握手过程中将确立加密传输数据的密码信息。TLS/SSL使用了非对称加密，对称加密以及hash等。具体过程。具体过程参考【http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html】，HTTPS相对于HTTP，虽然提供了安全保证，但是会带来一些时间上的损耗，比如握手和加密等过程，是否需要使用HTTPS需要根据在安全与性能方面做出权衡。
主要发生在客户端。发送HTTP请求的过程就是构建HTTP请求的报文并通过TCP协议发送到服务器指定端口（HTTP协议80/8080，HTTPS协议443）。HTTP请求报文就是由：请求行，请求报头，请求正文组成。
。后端从在固定的端口接收到TCP报文开始，这一部分对应于编程语言中的socket。它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。这一部分工作一般是由Web服务器去进行，经常使用的Web服务器有Tomcat, Jetty和Netty等等。
HTTP响应报文也是由三部分组成: 状态码, 响应报头和响应报文。
浏览器在收到HTML,CSS,JS文件后，它是如何把页面呈现到屏幕上的？下图对应的就是WebKit渲染的过程。
浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。
JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，也就是说，在同一个时间内只能做一件事，所有的任务都需要排队，前一个任务结束，后一个任务才能开始。但是又存在某些任务比较耗时，如IO读写等，所以需要一种机制可以先执行排在后面的任务，这就是：同步任务(synchronous)和异步任务(asynchronous)。JS的执行机制就可以看做是一个主线程加上一个任务队列(task queue)。同步任务就是放在主线程上执行的任务，异步任务是放在任务队列中的任务。所有的同步任务在主线程上执行，形成一个执行栈;异步任务有了运行结果就会在任务队列中放置一个事件；脚本运行时先依次运行执行栈，然后会从任务队列里提取事件，运行任务队列中的任务，这个过程是不断重复的，所以又叫做事件循环(Event loop)。
浏览器在解析过程中，如果遇到请求外部资源时，如图像,iconfont,JS等。浏览器将重复1-6过程下载该资源。请求过程是异步的，并不会影响HTML文档进行加载，但是当文档加载过程中遇到JS文件，HTML文档会挂起渲染过程，不仅要等到文档中JS文件加载完毕还要等待解析执行完毕，才会继续HTML的渲染过程。原因是因为JS有可能修改DOM结构，这就意味着JS执行完成前，后续所有资源的下载是没有必要的，这就是JS阻塞后续资源下载的根本原因。CSS文件的加载不影响JS文件的加载，但是却影响JS文件的执行。JS代码执行前浏览器必须保证CSS文件已经下载并加载完毕。
