前端技术-HTML页面的加载

HTML页面的加载

HTML页面的加载其实是基于http过程+浏览器对数据的解析渲染。

http协议的请求过程是基于TCP协议的。http是要基于TCP链接基础上，简单的说，TCP单纯创建链接，不涉及任何咱们须要请求的实际数据，简单的传输。http基于TCP创建的链接来收发数据，即实际应用上来的。

一个HTML页面的加载的交互流程大体以下：

0.输入URL
1.解析URL
2.构造并发送HTTP请求
服务器的永久重定向响应（从 http://example.com 到 http://www.example.com）
浏览器跟踪重定向地址
3.HTTP报文传输过程
4.服务器接受并处理HTTP报文
5.服务器构造并发送响应报文（传输过程略）
6.浏览器接收报文，并开始构建页面
7.（可选）浏览器发送嵌入在 HTML 中的静态资源如图片、音频、视频、CSS、JS等等）
8.（可选）浏览器发送Ajax异步请求（处理过程略）
9.页面构建完成

一.http过程

http协议的请求过程是基于TCP协议的。其实是TCP/IP协议簇的共同做用。

1.TCP/IP协议

TCP/IP协议，Transmission Control Protocol/Internet Protocol的简写，中译名为传输控制协议/因特网互联协议，又名网络通信协议，是Internet最基本的协议、Internet国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成的协议簇。它是计算机网络的的实际分层方式。

计算机网络的分层

第一种ISO/OSI模型，即开放式通讯系统互联参考模型（Open System Interconnection Reference Model），是国际标准化组织（ISO）提出的一个试图使各类计算机在世界范围内互连为网络的标准框架，简称OSI。但是实践中没有普遍应用。

层	简介	协议
第一层：物理层（PhysicalLayer)	规定通讯设备的机械的、电气的、功能的和过程的特性，用以创建、维护和拆除物理链路链接。具体地讲，机械特性规定了网络链接时所需接插件的规格尺寸、引脚数量和排列状况等；电气特性规定了在物理链接上传输bit流时线路上信号电平的大小、阻抗匹配、传输速率距离限制等；功能特性是指对各个信号先分配确切的信号含义，即定义了DTE和DCE之间各个线路的功能；规程特性定义了利用信号线进行bit流传输的一组操做规程，是指在物理链接的创建、维护、交换信息是，DTE和DCE双放在各电路上的动做系列。 在这一层，数据的单位称为比特（bit）。	属于物理层定义的典型规范表明包括：EIA/TIA RS-23二、EIA/TIA RS-44九、V.3五、RJ-45等。
第二层：数据链路层（DataLinkLayer)	在物理层提供比特流服务的基础上，创建相邻结点之间的数据链路，经过差错控制提供数据帧（Frame）在信道上无差错的传输，并进行各电路上的动做系列。  数据链路层在不可靠的物理介质上提供可靠的传输。该层的做用包括：物理地址寻址、数据的成帧、流量控制、数据的检错、重发等。 在这一层，数据的单位称为帧（frame）。	数据链路层协议的表明包括：SDLC、HDLC、PPP、STP、帧中继等。
第三层是网络层(Network layer)	在计算机网络中进行通讯的两个计算机之间可能会通过不少个数据链路，也可能还要通过不少通讯子网。网络层的任务就是选择合适的网间路由和交换结点， 确保数据及时传送。网络层将数据链路层提供的帧组成数据包，包中封装有网络层包头，其中含有逻辑地址信息- -源站点和目的站点地址的网络地址。 若是你在谈论一个IP地址，那么你是在处理第3层的问题，这是“数据包”问题，而不是第2层的“帧”。IP是第3层问题的一部分，此外还有一些路由协议和地址解析协议（ARP）。有关路由的一切事情都在第3层处理。地址解析和路由是3层的重要目的。网络层还能够实现拥塞控制、网际互连等功能。 在这一层，数据的单位称为数据包（packet）。	网络层协议的表明包括：IP、IPX、RIP、OSPF等。
第四层是处理信息的传输层(Transport layer)	第4层的数据单元也称做数据包（packets）。可是，当你谈论TCP等具体的协议时又有特殊的叫法，TCP的数据单元称为段（segments）而UDP协议的数据单元称为“数据报（datagrams）”。这个层负责获取所有信息，所以，它必须跟踪数据单元碎片、乱序到达的数据包和其它在传输过程当中可能发生的危险。第4层为上层提供端到端（最终用户到最终用户）的透明的、可靠的数据传输服务。所为透明的传输是指在通讯过程当中传输层对上层屏蔽了通讯传输系统的具体细节。	传输层协议的表明包括：TCP、UDP、SPX等。
第五层是会话层(Session layer)	这一层也能够称为会晤层或对话层，在会话层及以上的高层次中，数据传送的单位再也不另外命名，统称为报文。会话层不参与具体的传输，它提供包括访问验证和会话管理在内的创建和维护应用之间通讯的机制。如服务器验证用户登陆即是由会话层完成的。
第六层是表示层(Presentation layer)	这一层主要解决用户信息的语法表示问题。它将欲交换的数据从适合于某一用户的抽象语法，转换为适合于OSI系统内部使用的传送语法。即提供格式化的表示和转换数据服务。数据的压缩和解压缩， 加密和解密等工做都由表示层负责。
第七层应用层(Application layer)	应用层为操做系统或网络应用程序提供访问网络服务的接口。	应用层协议的表明包括：Telnet、FTP、HTTP、SNMP等。

第二种TCP/IP协议模型（Transmission Control Protocol/Internet Protocol），包含了一系列构成互联网基础的网络协议，是Internet的核心协议。根据实际状况将ISO的OSI模型改造为5层，这种模型具备现实可行性。目前已成为事实上的国际标准。TCP/IP协议簇是一组不一样层次上的多个协议的组合，一般被认为是一个五层协议系统，与OSI的七层模型相对应。

TCP/IP协议簇中不一样层次的协议：

(1). 链路层 
也称做数据链路层或网络接口层（在第一个图中为网络接口层和硬件层），一般包括操做系统中的设备驱动程序和计算机中对应的网络接口卡。它们一块儿处理与电缆（或其余任何传输媒介）的物理接口细节。ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换IP层和网络接口层使用的地址。     
(2). 网络层
也称做互联网层（在第一个图中为网际层），处理分组在网络中的活动，例如分组的选路。在TCP/IP协议族中，网络层协议包括IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。     
IP是一种网络层协议，提供的是一种不可靠的服务，它只是尽量快地把分组从源结点送到目的结点，可是并不提供任何可靠性保证。同时被TCP和UDP使用。TCP和UDP的每组数据都经过端系统和每一个中间路由器中的IP层在互联网中进行传输。  IP层接收由更低层（网络接口层例如以太网设备驱动程序）发来的数据包，并把该数据包发送到更高层---TCP或UDP层；相反，IP层也把从TCP或UDP层接收来的数据包传送到更低层。IP数据包是不可靠的，由于IP并无作任何事情来确认数据包是按顺序发送的或者没有被破坏。IP数据包中含有发送它的主机的地址（源地址）和接收它的主机的地址（目的地址）。   
ICMP是IP协议的附属协议（PING是最经常使用的基于ICMP的服务）。IP层用它来与其余主机或路由器交换错误报文和其余重要信息。  IGMP是Internet组管理协议。它用来把一个UDP数据报多播到多个主机。
(3). 传输层
主要为两台主机上的应用程序提供端到端的通讯。在TCP/IP协议族中，有两个互不相同的传输协议：TCP（传输控制协议）和UDP（用户数据报协议）。     
TCP为两台主机提供高可靠性的数据通讯。它所作的工做包括把应用程序交给它的数据分红合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。因为运输层提供了高可靠性的端到端的通讯，所以应用层能够忽略全部这些细节。为了提供可靠的服务，TCP采用了超时重传、发送和接收端到端的确认分组等机制。  UDP则为应用层提供一种很是简单的服务。它只是把称做数据报的分组从一台主机发送到另外一台主机，但并不保证该数据报能到达另外一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的必定字节数的信息）。UDP协议任何须需的可靠性必须由应用层来提供。     
(4). 应用层
应用层负责处理特定的应用程序细节。

接下来介绍TCP链接的创建。

2.TCP的三次握手与四次分手

TCP是面向链接的，不管哪一方向另外一方发送数据以前，都必须先在双方之间创建一条链接。在TCP/IP协议中，TCP协议提供可靠的链接服务，链接是经过三次握手进行初始化的。三次握手的目的是同步链接双方的序列号和确认号并交换 TCP窗口大小信息。先来看图说话。

三次握手

第一次握手：创建链接。客户端发送链接请求报文段，将SYN位置为1，Sequence Number为x；而后，客户端进入SYN_SEND状态，等待服务器的确认；
第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，须要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，本身本身还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述全部信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK报文段。而后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕之后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
完成了三次握手，客户端和服务器端就能够开始传送数据。

四次分手

当客户端和服务器经过三次握手创建了TCP链接之后，当数据传送完毕，确定是要断开TCP链接的啊。那对于TCP的断开链接，这里就有了神秘的“四次分手”。
第一次分手：主机1（可使客户端，也能够是服务器端），设置Sequence Number和Acknowledgment Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我也没有数据要发送了，能够进行关闭链接了；
第三次分手：主机2向主机1发送FIN报文段，请求关闭链接，同时主机2进入CLOSE_WAIT状态；
第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，而后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段之后，就关闭链接；此时，主机1等待2MSL后依然没有收到回复，则证实Server端已正常关闭，那好，主机1也能够关闭链接了。发送完毕以后，客户端进入等待状态，等待两个时间周期。关闭。
至此，TCP的四次分手就这么愉快的完成了。当你看到这里，你的脑子里会有不少的疑问，不少的不懂，感受很凌乱；没事，咱们继续总结。

为何要三次握手

既然总结了TCP的三次握手，那为何非要三次呢？怎么以为两次就能够完成了。

为了防止已失效的链接请求报文段忽然又传送到了服务端，于是产生错误。

举例以下：

“已失效的链接请求报文段”的产生在这样一种状况下：client发出的第一个链接请求报文段并无丢失，而是在某个网络结点长时间的滞留了，以至延误到链接释放之后的某个时间才到达server。原本这是一个早已失效的报文段。但server收到此失效的链接请求报文段后，就误认为是client再次发出的一个新的链接请求。因而就向client发出确认报文段，赞成创建链接。假设不采用“三次握手”，那么只要server发出确认，新的链接就创建了。因为如今client并无发出创建链接的请求，所以不会理睬server的确认，也不会向server发送数据。但server却觉得新的运输链接已经创建，并一直等待client发来数据。这样，server的不少资源就白白浪费掉了。采用“三次握手”的办法能够防止上述现象发生。例如刚才那种状况，client不会向server的确认发出确认。server因为收不到确认，就知道client并无要求创建链接。”
这就很明白了，防止了服务器端的一直等待而浪费资源。

那四次分手又是为什么呢？

TCP协议是一种面向链接的、可靠的、基于字节流的运输层通讯协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经所有发送完毕了；可是，这个时候主机1仍是能够接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，可是主机2仍是能够发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，以后彼此就会愉快的中断此次TCP链接。

为何四次分手TIME_WAIT状态还须要等2MSL后才能返回到CLOSED状态？

这是由于虽然双方都赞成关闭链接了，并且握手的4个报文也都协调和发送完毕，按理能够直接回到CLOSED状态（就比如从SYN_SEND状态到ESTABLISH状态那样）；可是由于咱们必需要假想网络是不可靠的，你没法保证你最后发送的ACK报文会必定被对方收到，所以对方处于LAST_ACK状态下的SOCKET可能会由于超时未收到ACK报文，而重发FIN报文，因此这个TIME_WAIT状态的做用就是用来重发可能丢失的ACK报文。
一、  客户端的最后一个ACK报文在传输的时候丢失，服务器并无接收到这个报文。这个候。
服务器就会超时重传这个FIN消息，而后客户端就会从新返回最后一个ACK报文，等待两个时间周期，完成关闭。若是不等待这两个时间周期，服务器重传的那条消息就不会收到。服务器就由于接收不到客户端的信息而没法正常关闭。
二、  预防上一次在三次握手中提到的失效的报文干扰。两个时间周期过去以后，全部的报文都会在网络中消失，保证下一次从新链接的时候有乱七八糟的报文影响。

TCP创建了链接，咱们看看http是在TCP链接基础上进行请求的。

3.HTTP协议详解

HTTP是一个属于应用层的面向对象的协议，因为其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，通过几年的使用与发展，获得不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工做正在进行之中，并且HTTP-NG(Next Generation of HTTP)的建议已经提出。
HTTP协议的主要特色可归纳以下：

1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法经常使用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不一样。因为HTTP协议简单，使得HTTP服务器的程序规模小，于是通讯速度很快。
3.灵活：HTTP容许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4.无链接：无链接的含义是限制每次链接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开链接。采用这种方式能够节省传输时间。
5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息，则它必须重传，这样可能致使每次链接传送的数据量增大。另外一方面，在服务器不须要先前信息时它的应答就较快。

HTTP协议之URL

http URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式以下：
http://host[":"port][abs_path]
http表示要经过HTTP协议来定位网络资源；
host表示合法的Internet主机域名或者IP地址；
port指定一个端口号，为空则使用缺省端口 80；
abs_path指定请求资源的URI；若是URL中没有给出abs_path，那么当它做为请求URI时，必须以“/”的形式给出，一般这个工做浏览器自动帮咱们完成。

如：

一、输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
二、http:192.168.0.116:8080/index.jsp

HTTP协议之请求

http请求由三部分组成，分别是：请求行、消息报头、请求正文

Request 消息分为3部分，第一部分叫请求行， 第二部分叫http header, 第三部分是body. header和body之间有个空行， 结构以下图

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式以下：

Method Request-URI HTTP-Version CRLF

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了做为结尾的CRLF外，不容许出现单独的CR或LF字符）。

请求方法（全部方法全为大写）有多种，各个方法的解释以下：

GET     请求获取Request-URI所标识的资源
POST    在Request-URI所标识的资源后附加新的数据
HEAD    请求获取由Request-URI所标识的资源的响应消息报头
PUT     请求服务器存储一个资源，并用Request-URI做为其标识
DELETE  请求服务器删除Request-URI所标识的资源
TRACE   请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留未来使用
OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

HEAD方法与GET方法几乎是同样的，对于HEAD请求的回应部分来讲，它的HTTP头部中包含的信息与经过GET请求所获得的信息是相同的。利用这个方法，没必要传输整个资源内容，就能够获得Request-URI所标识的资源的信息。该方法经常使用于测试超连接的有效性，是否能够访问，以及最近是否更新。

应用：
GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源

POST方法要求被请求服务器接受附在请求后面的数据，经常使用于提交表单。

当使用的是"GET" 方法的时候， body是为空的
好比咱们打开博客园首页的request 以下

GET http://www.cnblogs.com/ HTTP/1.1
Host: www.cnblogs.com

咱们用Fiddler 捕捉一个博客园登陆的Request 而后分析下它的结构， 在Inspectors tab下以Raw的方式能够看到完整的Request的消息，   以下图

 

get和post：

根据HTTP规范，Get是向服务器发索取数据的一种请求（GET获取信息是安全的和幂等的），而Post是向服务器提交数据的一种请求。

在HTML中：

相同点：均可（带参数）以向服务器发送请求。GET和POST只是发送机制不一样，严格是并不区分一个取一个发，但会根据状况考虑哪一种方式更合适。

主要用于from表单的提交（html的默认提交方式为get而不是post），以及ajax获取数据。

不一样点：

get是把参数数据队列加到提交表单的ACTION属性所指的URL中，值和表单内各个字段一一对应，在URL中能够看到。post是经过HTTP post机制，将表单内各个字段与其内容放置在HTML BODY中一块儿传送到ACTION属性所指的URL地址。用户看不到这个过程。
GET的URL会有长度上的限制，则POST的数据则能够很是大。
POST比GET安全，由于数据在地址栏上不可见。
get请求需注意缓存问题,post请求不需担忧这个问题。
post请求必须设置Content-Type值为application/x-form-www-urlencoded
在客户端使用get请求时,服务器端使用Request.QueryString来获取参数,而客户端使用post请求时,服务器端使用Request.Form来获取参数.

建议：
一、get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
二、在作数据查询时，建议用Get方式；而在作数据添加、修改或删除时，建议用Post方式，例如form中的内容；

不一样点的解释：

在HTTP中：

1. GET和POST与数据如何传递没有关系

GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪一个Method与应用层的数据如何传输是没有相互关系的。

HTTP没有要求，若是Method是POST数据就要放在BODY中。也没有要求，若是Method是GET，数据（参数）就必定要放在URL中而不能放在BODY中。
这只是HTML标准对HTTP协议的用法的约定。

2. HTTP协议对GET和POST都没有对长度的限制

HTTP协议明确地指出了，HTTP头和Body都没有长度的要求。而对于URL长度上的限制，有两方面的缘由形成：

浏览器。听说早期的浏览器会对URL长度作限制。听说IE对URL长度会限制在2048个字符内。
服务器。URL长了，对服务器处理也是一种负担。多数服务器出于安全、稳定方面的考虑，会给URL长度加限制。可是这个限制是针对全部HTTP请求的，与GET、POST没有关系。

3.安全不安全和GET、POST没有关系

并且，现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出，可是如今的Web Server又不是只给浏览器用，已经彻底地超出了HTML服务器的范畴了。

HTTP协议之响应

在接收和解释请求消息后，服务器返回一个HTTP响应消息。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

第一部分叫request line, 第二部分叫request header，第三部分是body. header和body之间也有个空行，  结构以下图

状态行格式以下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。
状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操做
4xx：客户端错误--请求有语法错误或请求没法实现
5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码、状态描述、说明：

200 OK      //客户端请求成功
400 Bad Request  //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经受权，这个状态代码必须和WWW-Authenticate报头域一块儿使用
403 Forbidden  //服务器收到请求，可是拒绝提供服务
404 Not Found  //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable  //服务器当前不能处理客户端的请求，一段时间后可能恢复正常
eg：HTTP/1.1 200 OK （CRLF）

 

咱们用Fiddler 捕捉一个博客园首页的Response而后分析下它的结构， 在Inspectors tab下以Raw的方式能够看到完整的Response的消息，   以下图

HTTPS协议：

HTTPS应用了Netscape的安全套接字层（SSL）做为HTTP应用层的子层。SSL协议位于TCP/IP协议与各类应用层协议之间，为数据通信提供安全支持。SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它创建在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它创建在SSL记录协议之上，用于在实际的数据传输开始前，通信双方进行身份认证、协商加密算法、交换加密密钥等。

SSL协议通讯过程

(1) 浏览器发送一个链接请求给服务器;服务器将本身的证书(包含服务器公钥S_PuKey)、对称加密算法种类及其余相关信息返回客户端;
(2) 客户端浏览器检查服务器传送到CA证书是否由本身信赖的CA中心签发。如果，执行4步;不然，给客户一个警告信息：询问是否继续访问。
(3) 客户端浏览器比较证书里的信息，如证书有效期、服务器域名和公钥S_PK，与服务器传回的信息是否一致，若是一致，则浏览器完成对服务器的身份认证。
(4) 服务器要求客户端发送客户端证书(包含客户端公钥C_PuKey)、支持的对称加密方案及其余相关信息。收到后，服务器进行相同的身份认证，若没有经过验证，则拒绝链接;
(5) 服务器根据客户端浏览器发送到密码种类，选择一种加密程度最高的方案，用客户端公钥C_PuKey加密后通知到浏览器;
(6) 客户端经过私钥C_PrKey解密后，得知服务器选择的加密方案，并选择一个通话密钥key，接着用服务器公钥S_PuKey加密后发送给服务器;
(7) 服务器接收到的浏览器传送到消息，用私钥S_PrKey解密，得到通话密钥key。
(8) 接下来的数据传输都使用该对称密钥key进行加密。
上面所述的是双向认证 SSL 协议的具体通信过程，服务器和用户双方必须都有证书。因而可知，SSL协议是经过非对称密钥机制保证双方身份认证，并完成创建链接，在实际数据通讯时经过对称密钥机制保障数据安全性

 

https是一个安全通讯通道，它基于HTTP开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来讲它是HTTP的安全版。

两者的区别：

协议基础不一样：Https在Http下加入了SSL层。http是超文本传输协议，信息是明文传输，https 则是具备安全性的ssl加密传输协议
通信方式不一样：Https在数据通讯以前须要客户端、服务器进行握手(身份认证)，创建链接后，传输数据通过加密，通讯端口443。
https协议须要到ca申请证书，通常免费证书不多，须要交费。
http的链接很简单,是无状态的

4.从实际上的数据应用来讲http的过程

在前面客户端和应用服务器创建TCP链接以后，就须要用http协议来传送数据了，HTTP协议简单来讲，仍是请求，确认，链接。
整体就是C发送一个HTTP请求给S，S收到了这个http请求，而后返回给Chttp响应，而后C的中间件或者说浏览器把这些数据渲染成为了网页，展现在用户面前。
第一：发送一个http请求给S，这个请求包括请求头和请求内容：
request header：
包括了，1.请求的方法是POST/GET,请求的URL，http协议版本2.请求的数据，和编码方式3是否有cookie和cooies，是否缓存等。
post和get请求方式的区别是，get把请求内容放在URL后面，可是URL长度有限制。而post是以表单的形势，适合要输入密码之类的，由于不在URL中显示，因此比较安全。
request body：
即请求的内容.
第二：S收到了http请求，而后根据请求头，返回http响应。
response header:包括了1.cookies或者sessions2.状态吗3.内容大小等
response body：
即响应的内容，包括，JS什么的。
第三，C收到了之后，就由浏览器完成一系列的渲染，包括执行JS脚本等。
这就是我所理解的webTCP,HTTP基础知识，待续。。。。。

例如：

在上图中，可清晰的看到客户端浏览器（ip为192.168.2.33）与服务器的交互过程：
1）No1：浏览器（192.168.2.33）向服务器（220.181.50.118）发出链接请求。此为TCP三次握手第一步，此时从图中能够看出，为SYN，seq:X （x=0）
2）No2：服务器（220.181.50.118）回应了浏览器（192.168.2.33）的请求，并要求确认，此时为：SYN，ACK，此时seq：y（y为0），ACK：x+1（为1）。此为三次握手的第二步；
3）No3：浏览器（192.168.2.33）回应了服务器（220.181.50.118）的确认，链接成功。为：ACK，此时seq：x+1（为1），ACK：y+1（为1）。此为三次握手的第三步；
4）No4：浏览器（192.168.2.33）发出一个页面HTTP请求；
5）No5：服务器（220.181.50.118）确认；
6）No6：服务器（220.181.50.118）发送数据；
7）No7：客户端浏览器（192.168.2.33）确认；
8）No14：客户端（192.168.2.33）发出一个图片HTTP请求；
9）No15：服务器（220.181.50.118）发送状态响应码200 OK
……

二.浏览器是怎样渲染HTML的（渲染引擎，HTML解析）

1.渲染引擎

渲染引擎的职责是……渲染，也就是把请求的内容显示到浏览器屏幕上。

默认状况下渲染引擎能够显示HTML，XML文档以及图片。 经过插件（浏览器扩展）它能够显示其它类型文档。好比使用PDF viewer插件显示PDF文件。咱们专一渲染引擎的主要用途——显示用CSS格式化的HTML与图片。

各类渲染引擎
咱们提到的Firefox, Safari两种浏览器构建于两种渲染引擎之上：Firefox使用Gecko —— Mozilla自家的渲染引擎；Safari 和 Chrome 都使用 Webkit。

2.渲染引擎的基本工做流程

解析ＨＴＭＬ
构建ＤＯＭ树
渲染树构建
渲染树布局
绘制渲染树

渲染引擎开始于从网络层获取请求内容，通常是不超过8Ｋ的数据块。接下来就是渲染引擎的基本工做流程：

渲染引擎会解析ＨＴＭＬ文档并把标签转换成内容树中的ＤＯＭ节点。它会解析style元素和外部文件中的样式数据。样式数据和ＨＴＭＬ中的显示控制将共同用来建立另外一棵树——渲染树。
渲染树包含带有颜色，尺寸等显示属性的矩形。这些矩形的顺序与显示顺序一致。
渲染树构建完成后就是”布局”处理，也就是肯定每一个节点在屏幕上的确切显示位置。 下一个步骤是”绘制” —— 遍历渲染树并用ＵＩ后端层将每个节点绘制出来。
必定要理解这是一个缓慢的过程，为了更好的用户体验，渲染引擎会尝试尽快的把内容显示出来。它不会等到全部ＨＴＭＬ都被解析完才建立并布局渲染树。它会在处理后续内容的同时把处理过的局部内容先展现出来。

主要流程示例

Webkit主要流程

 

Mozilla的Gecko渲染引擎主要流程

从上能够看出，尽管Webkit与Gecko使用略微不一样的术语，这个过程仍是基本相同的。
Gecko 里把格式化好的可视元素称作“帧树”（Frame tree）。每一个元素就是一个帧（frame）。 Webkit 则使用”渲染树”这个术语，渲染树由”渲染对象”组成。Webkit 里使用”layout”表示元素的布局，Gecko则称为”Reflow”。Webkit使用”Attachment”来链接DOM节点与可视化信息以构建渲染树。一个非语义上的小差异是Gecko在ＨＴＭＬ与ＤＯＭ树之间有一个附加的层 ，称做”content sink”，是建立ＤＯＭ对象的工厂。

3.解析

解析一个文档意味着把它翻译成有意义的结构以供代码使用。解析的结果一般是一个表征文档的由节点组成的树，称为解析树或句法树。

如下是编译原理知识。这里只做通常性介绍，为下面的HTML解析打基础。

语法

解析是基于文档所遵循的语法规则——书写所用的语言或格式——来进行的。每一种能够解析的格式必须由肯定的语法与词汇组成。这被称之为上下文无关语法。 人类语言并不是此种语言，因此不能用常规的解析技术来解析。
解析器——词法分析器组合
解析器有两个处理过程——词法分析与句法分析。
词法分析负责把输入切分红符号序列，符号是语言的词汇——由该语言全部合法的单词组成。
句法分析是对该语言句法法则的应用。
解析器一般把工做分给两个组件——分词程序负责把输入切分红合法符号序列，解析程序负责按照句法规则分析文档结构和构建句法树。词法分析器知道如何过滤像空格，换行之类的无关字符。

从源文档到解析树（文档，词法分析，句法分析，解析树）。
解析过程是交互式的。解析器一般会从词法分析器获取新符号并尝试匹配句法规则。若是匹配成功，就在句法树上建立相应的节点，并继续从词法分析器获取下一个符号。若是没有匹配的规则，解析器会内部保存这个符号，并继续从词法分析器获取符号，直到内部保存的全部符号可以成功匹配一个规则。若是最终没法匹配，解析器会抛出异常。这意味着文档无效，含有句法错误。

转换

多数状况下解析树并不是最终结果。解析常常是为了从输入文档转换成另一种格式。好比编译器要把源码编译成机器码，会首先解析成解析树，再把解析树转换成机器码。

编译过程（源码，解析，解析树，转换，机器码）。

咱们说过常规解析器只能解析上下文无关语法的语言。这种语言的一个直觉的定义是它的句法能够用BNF完整的表达。

解析器的类型
解析器有两种基本类型——自上而下解析器和自下而上解析器。主观上能够认为自上而下的解析器从上层句法结构开始尝试匹配句法；自下而上的则从输入开始，慢慢转换成句法规则，从底层规则开始，直到上层规则所有匹配。

4.HTML解析器

ＨＴＭＬ解析器的工做是解析ＨＴＭＬ标记到解析树。

HTML的定义使用DTD文件。这种格式用来定义SGML族语言，它包含对全部容许的元素的定义，包括它们的属性和层级关系。如咱们前面所说，HTML DTD构不成上下文无关语法。
DTD有几种不一样类型。严格模式彻底尊守规范，但其它模式为了向前兼容可能包含对早期浏览器所用标签的支持。

DOM

解析器输出的树是由ＤＯＭ元素和属性节点组成的。DOM的全称为：Document Object Model。它是ＨＴＭＬ文档的对象化描述，也是ＨＴＭＬ元素与外界（如Javascript）的接口。
ＤＯＭ与标签几乎有着一一对应的关系，以下面的标签
<html>
    <body>
        <p>
            Hello World
        </p>
        <div> <img src="example.png"/></div>
    </body>
</html>
会被转换成如的ＤＯＭ树：

与HTML同样，DOM规范也由w3c组织制订。
当咱们说树中包含ＤＯＭ节点时，意思就是这个树是由实现了ＤＯＭ接口的元素组成。这些实现包含了其它一些浏览器内部所需的属性。

HTML解析

如咱们前面看到的，HTML没法使用自上而下或自下而上的解析器来解析。
理由以下：
语言的宽容特色

浏览器须要对无效HTML提供容错性的事实。
解析过程的反复。一般解析过程当中源码不会变化。但在HTML中，script标签包含”document.write”时能够添加内容，即解析过程实际上还会改变源码。

浏览器建立了本身的解析器来解析HTML文档。
HTML5规范里对解析算法有具体的说明，解析由两部分组成：分词与构建树。
分词属于词法分析部分，它把输入解析成符号序列。在HTML中符号就是开始标签，结束标签，属性名称和属生值。
分词器识别这些符号并将其送入树构建者，而后继续分析处理下一个符号，直到输入结束。

HTML解析流程 (源自HTML5规范)

分词算法

算法的输出是HTML符号。算法能够用状态机来描述。 每个状态从输入流中消费一个或多个字符，并根据它们更新下一状态。决策受当前符号状态和树的构建状态影响。这意味着一样的字符可能会产生不一样的结果，取决于当前的状态。用一个例子来看看它的原理。

基础示例，分析下面的标签:
<html>
    <body>
        Hello world
    </body>
</html>
初始状态是”Data state”，当遇到”<“时状态改成“Tag open state”。吃掉”a-z”字符组成的符号后产生了”Start tag token”，状态变动为“Tag name state”。咱们一直保持此状态，直到遇到”>”。每一个字符都被追加到新的符号名上。在咱们的例子中，解出的符号就是”html”。

当碰到”>”时，当前符号完成，状态改回“Data state”。”<body>”标签将会以一样的方式处理。如今”html”与”body”标签都完成了，咱们回到“Data state”状态。吃掉”H”（”Hello world”第一个字母）时会产生一个字符符号，直到碰到”</body>”的”<“符号，咱们就完成了一个字符符号”Hello world”。

如今咱们回到“Tag open state”状态。吃掉下一个输入”/”时会产生一个”end tag token”并变动为“Tag name state”状态。一样，此状态保持到咱们碰到”>”时。这时新标签符号完成，咱们又回到“Data state”。一样”</html>”也会被这样处理。

树的构建算法

当解析器被建立时，文档对象也被建立了。在树的构建过程当中DOM树的根节点（Documen）将被修改，元素被添加到上面去。每一个分词器完成的节点都会被树构建器处理。规范中定义了每个符号与哪一个DOM对象相关。除了把元素添加到DOM树外，它还会被添加到一个开放元素堆栈。这个堆栈用于纠正嵌套错误和标签未关闭错误。这个算法也用状态机描述，它的状态叫作”insertion modes”。

让咱们看看下面输入的树构建过程：
<html>
    <body>
        Hello world
    </body>
</html>
树的构建过程当中，输入就是分词过程当中获得的符号序列。第一个模式叫“initial mode”。接收 html 符号后会变成“before html”模式并从新处理此模式中的符号。这会建立一个HTMLHtmlElement元素并追加到根文档节点。

而后状态改变为“before head”。咱们收到”body”时，会隐式建立一个HTMLHeadElement，尽管咱们没有这个标签，它也会被建立并添加到树中。

如今咱们进入“in head”模式，而后是“after head”，Body会被从新处理，建立HTMLBodyElement元素并插入，而后进入“in body”模式。

字符符号”Hello world”收到后会建立一个”Text”节点，全部字符都被一一追加到上面。

收到body结束标签后进入 “after body” 模式，收到html结束标签后进入“after after body”模式。全部符号处理完后将终止解析。

解析结束后的动做

在这一阶段浏览器会把文档标记为交互模式，并开始解析deferred模式的script。”deferred”意味着脚本应该在文档解析完成后执行。脚本处理完成后将进入”complete”状态，”load”事件发生。
HTML5规范中包含了完整的算法： http://www.w3.org/TR/html5/syntax.html#html-parser

浏览器的容错

你永远不会看到HTML页面语法错误。浏览器会修正错误并继续。

三.HTML页面的加载总体流程

从浏览器地址栏的请求连接开始，浏览器经过DNS解析查到域名映射的IP地址，成功以后浏览器端向此IP地址取得链接，成功链接以后，浏览器端将请 求头信息 经过HTTP协议向此IP地址所在服务器发起请求，服务器接受到请求以后等待处理，最后向浏览器端发回响应，此时在HTTP协议下，浏览器从服务器接收到 text/html类型的代码，浏览器开始显示此html，并获取其中内嵌资源地址，而后浏览器再发起请求来获取这些资源，并在浏览器的html中显示。

用户输入网址（假设是个html页面，而且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的。
浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
浏览器继续载入html中<body>部分的代码，而且CSS文件已经拿到手了，能够开始渲染页面了；
若是遇到语义解释性的标签嵌入文件（JS脚本，CSS样式），下载过程会启用单独链接进行下载。而且在下载后进行解析，解析过程当中，中止页面全部往下元素的下载，不能并行下载和解析。样式表在下载完成后，将和之前下载的全部样式表一块儿进行解析，解析完成后，将对此前全部元素（含之前已经渲染的）从新进行渲染。js也不能并行下载和解析
浏览器继续载入html中<body>部分的代码，而且CSS文件已经拿到手了，能够开始渲染页面了；
浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
服务器返回图片文件，因为图片占用了必定面积，影响了后面段落的排布，所以浏览器须要回过头来从新渲染这部分代码；
浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个<div> （style.display=”none”）。浏览器不得不从新渲染这部分代码；
直到运行到</html>。
还没完，经过操做页面运行Javascript代码，改变了DOM或样式，浏览器从新来过，向服务器请求资源文件，从新渲染页面。

-------------------------------------------------------------------------------------------------------------------------------------

完

转载需注明转载字样，标注原做者和原博文地址。

更多阅读：

http://jingyan.baidu.com/article/2fb0ba4048e15500f3ec5f7e.html

http://www.jellythink.com/archives/705

http://www.cnblogs.com/jtome/archive/2008/12/04/1347864.html

http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

http://www.chinaz.com/news/2012/0509/250601.shtml

http://wenku.baidu.com/link?url=u9QspfeUFh2SDo8sa8k-_VCdEUP-7QFNYEaKTFi_94ZLowEcdUEgVNnl8Or4bfc2XMaM1wHHQ7ddW7StfFJhiRqi9uTmlX6TJIqpF0Uyqpq

http://kb.cnblogs.com/page/130970/