【0179】Android 面试-网络相关

时间  2019-11-08
标签 android 面试 网络 相关 栏目 Android 繁體版
原文   原文链接

1.Http协议的基本认识

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（www.baidu.com）服务器传输超文本到本地浏览器的传送协议。css

HTTP是一个基于TCP/IP通讯协议来传递数据（HTML 文件, 图片文件, 查询结果等）。html

HTTP是一个属于应用层的面向对象的协议，因为其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，通过几年的使用与发展，获得不断地完善和扩展。前端

目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工做正在进行之中，并且HTTP-NG(Next Generation of HTTP)的建议已经提出。java

HTTP协议工做于客户端-服务端架构为上。web

浏览器做为HTTP客户端经过URL向HTTP服务端即WEB服务器发送全部请求。面试

Web服务器根据接收到的请求后，向客户端发送响应信息。算法

2.URI和URL的区别

【uri】编程

【url】跨域

HTTP之URL浏览器

HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和创建链接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息

URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。

如下面这个URL为例，介绍下普通URL的各部分组成：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

从上面的URL能够看出，一个完整的URL包括如下几部分：
1.协议部分：该URL的协议部分为“http：”，这表明网页使用的是HTTP协议。在Internet中能够使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符

2.域名部分：该URL的域名部分为“www.aspxfans.com”。一个URL中，也能够使用IP地址做为域名使用

3.端口部分：跟在域名后面的是端口，域名和端口之间使用“:”做为分隔符。端口不是一个URL必须的部分，若是省略端口部分，将采用默认端口

4.虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

5.文件名部分：

 从域名后的最后一个“/”开始到“？”为止，是文件名部分

 若是没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分

 若是没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。

本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，若是省略该部分，则使用默认的文件名

6.锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

7.参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数能够容许有多个参数，参数与参数之间用“&”做为分隔符

（原文：http://blog.csdn.net/ergouge/article/details/8185219 ）

URI和URL的区别

【 总结：URI标记了一个网络资源，仅此而已；  URL标记了一个WWW互联网资源（用地址标记），并给出了他的访问地址】

URI，是uniform resource identifier，统一资源标识符，用来惟一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片断、程序等都是一个来URI来定位的
URI通常由三部组成：
①访问资源的命名机制
②存放资源的主机名
③资源自身的名称，由路径表示，着重强调于资源。

URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL能够用来标识一个资源，并且还指明了如何locate这个资源。

URL是Internet上用来描述信息资源的字符串，主要用在各类WWW客户程序和服务器程序上，特别是著名的Mosaic。
采用URL能够用一种统一的格式来描述各类信息资源，包括文件、服务器的地址和目录等。URL通常由三部组成：
①协议(或称为服务方式)
②存有该资源的主机IP地址(有时也包括端口号)
③主机资源的具体地址。如目录和文件名等

URN，uniform resource name，统一资源命名，是经过名字来标识资源，好比mailto:java-net@java.sun.com。

URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。

URL和URN都是一种URI。

笼统地说，每一个 URL 都是 URI，但不必定每一个 URI 都是 URL。

这是由于 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一个URI实例能够表明绝对的，也能够是相对的，只要它符合URI的语法规则。而URL类则不只符合语义，还包含了定位该资源的信息，所以它不能是相对的。
在Java类库中，URI类不包含任何访问资源的方法，它惟一的做用就是解析。
相反的是，URL类能够打开一个到达资源的流。

3.http协议的特色

1.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法经常使用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不一样。因为HTTP协议简单，使得HTTP服务器的程序规模小，于是通讯速度很快。

2.灵活：HTTP容许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

3.无链接：无链接的含义是限制每次链接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开链接。采用这种方式能够节省传输时间。

4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺乏状态意味着若是后续处理须要前面的信息，则它必须重传，这样可能致使每次链接传送的数据量增大。另外一方面，在服务器不须要先前信息时它的应答就较快。
5.支持B/S及C/S模式。

3.1 http1.1/http2.0 区别

 

4. HTTP之请求消息Request

客户端发送一个HTTP请求到服务器的请求消息包括如下格式：

请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

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

【if-none-match参数】

【If-None-Match】

做用: If-None-Match和ETag一块儿工做，工做原理是在HTTP Response中添加ETag信息。

当用户再次请求该资源时，将在HTTP Request 中加入If-None-Match信息(ETag的值)。

若是服务器验证资源的ETag没有改变（该资源没有更新），将返回一个304状态告诉客户端使用本地缓存文件。

不然将返回200状态和新的资源和Etag.  使用这样的机制将提升网站的性能

例如: If-None-Match: "03f2b33c0bfcc1:0"

实例以下图

【User-Agent】

做用：告诉HTTP服务器， 客户端使用的操做系统和浏览器的名称和版本.

咱们上网登录论坛的时候，每每会看到一些欢迎信息，其中列出了你的操做系统的名称和版本，你所使用的浏览器的名称和版本，这每每让不少人感到很神奇，

实际上，服务器应用程序就是从User-Agent这个请求报头域中获取到这些信息User-Agent请求报头域容许客户端将它的操做系统、浏览器和其它属性告诉服务器。

例如： User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; CIBA; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; InfoPath.2; .NET4.0E)

【Accept】

做用： 浏览器端能够接受的媒体类型,

例如：  Accept: text/html  表明浏览器能够接受服务器回发的类型为 text/html  也就是咱们常说的html文档,

若是服务器没法返回text/html类型的数据,服务器应该返回一个406错误(non acceptable)

通配符 * 表明任意类型

例如  Accept: */*  表明浏览器能够处理全部类型,(通常浏览器发给服务器都是发这个)

【referer】

Referer头域容许客户端指定请求uri的源资源地址，这能够容许服务器生成回退链表，可用来登录、优化cache等。

他也容许废除的或错误的链接因为维护的目的被追踪。

若是请求的uri没有本身的uri地址，Referer不能被发送。若是指定的是部分uri地址，则此地址应该是一个相对地址。

【Accept-Encoding】：

做用： 浏览器申明本身接收的编码方法，一般指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate），（注意：这不是只字符编码）;

例如： Accept-Encoding: gzip, deflate

【Accept-Language】

做用： 浏览器申明本身接收的语言。 

语言跟字符集的区别：中文是语言，中文有多种字符集，好比big5，gb2312，gbk等等；

例如： Accept-Language: en-us

【If-Modified-Since】

做用： 把浏览器端缓存页面的最后修改时间发送到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行对比。

若是时间一致，那么返回304，客户端就直接使用本地缓存文件。若是时间不一致，就会返回200和新的文件内容。客户端接到以后，会丢弃旧文件，把新文件缓存起来，并显示在浏览器中.

例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT

实例以下图

5. HTTP之请求消息Response

一样使用Fiddler 查看Response header, 点击Inspectors tab ->Response tab-> headers  以下图所示

 咱们也按照Fiddler那样把header 进行分类，这样比较清晰也容易记忆。

Cache头域

Date

做用:  生成消息的具体时间和日期

例如：　Date: Sat, 11 Feb 2012 11:35:14 GMT 

 

Expires

做用: 浏览器会在指定过时时间内使用本地缓存

例如: Expires: Tue, 08 Feb 2022 11:35:14 GMT

 

cache-control

Cache-Control指定请求和响应遵循的缓存机制。

在请求消息或响应消息中设置Cache-Control并不会修改另外一个消息处理过程当中的缓存处理过程。

请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，

响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。

 

proxy-connection

例如：　Connection: keep-alive   当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP链接不会关闭，若是客户端再次访问这个服务器上的网页，会继续使用这一条已经创建的链接

例如：  Connection: close  表明一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP链接会关闭， 当客户端再次发送Request，须要从新创建TCP链接。

给浏览器设置了代理（Proxy）。而神器 Fiddler 的抓包原理就是让浏览器请求走它开的本地代理

 

Vary

做用：

例如: Vary: Accept-Encoding

 

Cookie/Login 头域

P3P

做用: 用于跨域设置Cookie, 这样能够解决iframe跨域访问cookie的问题

例如: P3P: CP=CURa ADMa DEVa PSAo PSDo OUR BUS UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR

 

Set-Cookie

做用： 很是重要的header, 用于把cookie 发送到客户端浏览器， 每个写入cookie都会生成一个Set-Cookie.

例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

 

Entity头域

ETag

做用:  和If-None-Match 配合使用。 （实例请看上节中If-None-Match的实例）

例如: ETag: "03f2b33c0bfcc1:0"

 

Last-Modified:

做用： 用于指示资源的最后修改日期和时间。（实例请看上节的If-Modified-Since的实例）

例如: Last-Modified: Wed, 21 Dec 2011 09:09:10 GMT

 

Content-Type

做用：WEB服务器告诉浏览器本身响应的对象的类型和字符集,

例如:

Content-Type: text/html; charset=utf-8

Content-Type:text/html;charset=GB2312

Content-Type: image/jpeg

 

Content-Length

指明实体正文的长度，以字节方式存储的十进制数字来表示。在数据下行的过程当中，Content-Length的方式要预先在服务器中缓存全部数据，而后全部数据再一古脑儿地发给客户端。

例如: Content-Length: 19847

 

Content-Encoding

WEB服务器代表本身使用了什么压缩方法（gzip，deflate）压缩响应中的对象。

例如：Content-Encoding：gzip

 

Content-Language

做用： WEB服务器告诉浏览器本身响应的对象的语言者

例如： Content-Language:da

 

Miscellaneous 头域

Server:

做用：指明HTTP服务器的软件信息

例如:Server: Microsoft-IIS/7.5

 

X-AspNet-Version:

做用：若是网站是用ASP.NET开发的，这个header用来表示ASP.NET的版本

例如: X-AspNet-Version: 4.0.30319

X-Powered-By:

做用：表示网站是用什么技术开发的

例如： X-Powered-By: ASP.NET

Location头域

Location

做用： 用于重定向一个新的位置, 包含新的URL地址

 实例请看304状态实例

6.状态码 

 Response 消息中的第一行叫作状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。

状态码用来告诉HTTP客户端,HTTP服务器是否产生了预期的Response.

HTTP/1.1中定义了5类状态码， 状态码由三位数字组成，第一个数字定义了响应的类别

1XX  提示信息 - 表示请求已被成功接收，继续处理

2XX  成功 - 表示请求已被成功接收，理解，接受

3XX  重定向 - 要完成请求必须进行更进一步的处理

4XX  客户端错误 -  请求有语法错误或请求没法实现

5XX  服务器端错误 -   服务器未能实现合法的请求

看看一些常见的状态码

200 OK

最多见的就是成功响应状态码200了， 这代表该请求被成功地完成，所请求的资源发送回客户端

以下图， 打开博客园首页

302 Found

重定向，新的URL会在response 中的Location中返回，浏览器将会自动使用新的URL发出新的Request

例如在IE中输入， http://www.baidu.com. HTTP服务器会返回302， IE取到Response中Location header的新URL, 又从新发送了一个Request.

304 Not Modified

表明上次的文档已经被缓存了， 还能够继续使用，

例如打开博客园首页, 发现不少Response 的status code 都是304

提示：　若是你不想使用本地缓存能够用Ctrl+F5 强制刷新页面

400 Bad Request  客户端请求与语法错误，不能被服务器所理解

403 Forbidden 服务器收到请求，可是拒绝提供服务

404 Not Found

请求资源不存在（输错了URL）

好比在IE中输入一个错误的URL， http://www.cnblogs.com/tesdf.aspx

 

500 Internal Server Error 服务器发生了不可预期的错误

503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常

7.常见的易混淆的问题

7.1 http1.0/http 1.1 区别

HTTP1.0产生的背景 
超文本传输协议（HyperText Transfer Protocol）伴随着计算机网络和浏览器的诞生，HTTP1.0也随之而来，处于计算机网络中的应用层。

HTTP1.0所作的优化 
咱们知道HTTP协议（应用层）是创建在TCP协议（传输层）之上，因此的HTTP协议的优化与瓶颈都是基于TCP协议自己的，

好比说咱们的TCP创建链接须要三次握手，断开链接须要四次挥手，以及每次链接带来的延迟时间，这些都是能够优化的角度。 
早在HTTP1.0创建的开始，主要是将HTML文档从Web服务器传输到客服端浏览器上，随着时间的推移，前端发展到如今，

HTML文档变得更加复杂了，里面可能有不少图片以及大量的css样式和js代码来显示界面，无论这些内容如何的变化，本质上都是基于HTTP协议的。

能够从如下几个方面进行优化

带宽：带宽这块目前基本已经解决了，如今已经不是拨号上网的时代了，在拨号上网时能够会成为影响网络请求的重要因素，如今网络基础设施已经获得质的升级，基本不会担忧因带宽带来影响网速问题。

延迟（三个方面）

【1】浏览器阻塞：浏览器对于同一个域名，同时只能有4个链接，就是说浏览器由于一些网络缘由阻塞请求，不一样浏览器的链接数是有限制的，当请求数达到浏览器最大链接数时，后续的请求就会被阻塞，直到前面的请求执行完毕后，才会接着后面链接请求。

【2】DNS查询：浏览器须要知道目标服务器的IP才能创建链接；将咱们的域名解析IP的地址就是所谓的DNS请求，一般能够利用DNS缓存来达到减小请求的目的，好比说反复查询某个域名的IP地址，不须要每次经过这个请求，而是DNS缓存就能够达到这个目的。

【3】创建链接：三次握手；HTTP协议是基于在TCP协议之上的，浏览器最快最快也只能在第三次握手后才能够携带HTTP请求报文达到真正创建链接的目的，可是这些链接是没法复用的，这就致使了每次请求都要进行三次握手，这是比较头痛的地方，尤为是在一些高延迟的场景，三次握手的延迟会更加明显。

7.2 HTTP1.1与HTTP1.0的具体区别

【缓存】缓存策略具备较大的不一样

HTTP/1.0中，If-Modified-Since头域使用的是绝对时间戳，精确到秒，但使用绝对时间会带来不一样机器上的时钟同步问题。

而HTTP/1.1中引入了一个ETag头域用于重激活机制，它的值entity tag能够用来惟一的描述一个资源。

请求消息中能够使用If-None-Match头域来匹配资源的entitytag是否有变化。

 【带宽优化及网络链接的使用】 

HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是须要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只须要显示一个文档的部份内容，又好比下载大文件时须要支持断点续传功能，而不是在发生断连后不得不从新下载完整的包。

HTTP/1.1中在请求消息中引入了range头域，它容许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。

HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，若是服务器由于权限拒绝了请求，就回送响应码401（Unauthorized）；

     若是服务器接收此请求就回送响应码100，客户端就能够继续发送带实体的完整请求了。

注意，HTTP/1.0的客户端不支持100响应码。但可让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。

【Host头的处理】

在HTTP1.0中认为每台服务器都绑定一个惟一的IP地址，所以，请求消息中的URL并无传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上能够存在多个虚拟主机（Multi-homed Web Servers），而且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中若是没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

 【长链接】

HTTP 1.0规定浏览器与服务器只保持短暂的链接，浏览器的每次请求都须要与服务器创建一个TCP链接，服务器完成请求处理后当即断开TCP链接，服务器不跟踪每一个客户也不记录过去的请求。

此外，因为大多数网页的流量都比较小，一次TCP链接不多能经过slow-start区，不利于提升带宽利用率。

HTTP 1.1支持长链接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP链接上能够传送多个HTTP请求和响应，减小了创建和关闭链接的消耗和延迟。

    例如：一个包含有许多图像的网页文件的多个请求和应答能够在一个链接中传输，但每一个单独的网页文件的请求和应答仍然须要使用各自的链接。

HTTP 1.1还容许客户端不用等待上一次请求结果返回，就能够发出下一次请求，但服务器端必须按照接收到客户端请求的前后顺序依次回送响应结果，以保证客户端可以区分出每次请求的响应内容，这样也显著地减小了整个下载过程所须要的时间。

在HTTP/1.0中，要创建长链接，能够在请求消息中包含Connection: Keep-Alive头域，若是服务器愿意维持这条链接，在响应消息中也会包含一个Connection: Keep-Alive的头域。同时，能够加入一些指令描述该长链接的属性，如max，timeout等。

7.3 http1.1和http1.0存在的问题

a.HTTP1.x在传输数据时，每次都须要从新创建链接，无疑增长了大量的延迟时间

b.HTTP1.x在传输数据时，全部传输的内容都是明文，客户端和服务器端都没法验证对方的身份

c.HTTP1.x在使用时，header里携带的内容过大，在必定程度上增长了传输的成本

d.虽然HTTP1.x支持了keep-alive,来弥补屡次建立链接产生的延迟，可是keep-alive使用多了一样会给服务端带来大量的性能压力

7.4 get/post方法的区别

get和post是HTTP与服务器交互的方式， 
说到方式，其实总共有四种：put，delete，post，get。 
他们的做用分别是对服务器资源的增，删，改，查。 
因此，get是获取数据，post是修改数据。

1)提交的数据

get把请求的数据放在url上，即HTTP协议头上，其格式为： 
以?分割URL和传输数据，参数之间以&相连。 
数据若是是英文字母/数字，原样发送， 
若是是空格，转换为+， 
若是是中文/其余字符，则直接把字符串用BASE64加密，及“%”加上“字符串的16进制ASCII码”。

post把数据放在HTTP的包体内（requrest body）

2)提交的数据大小是否有限制

get提交的数据最大是2k（原则上url长度无限制，那么get提交的数据也没有限制咯？限制实际上取决于浏览器，(大多数)浏览器一般都会限制url长度在2K个字节，即便(大多数)服务器最多处理64K大小的url。也没有卵用。）。 
post理论上没有限制。实际上IIS4中最大量为80KB，IIS5中为100KB。

3)取得变量的值使用的方法不同

get使用的方法：Request.QueryString

post使用的方法： Request.From

4)安全问题

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留

GET产生一个TCP数据包，浏览器会把http header和data一并发送出去，服务器响应200(返回数据); 
POST产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)。

GET在浏览器回退时是无害的，POST会再次提交请求。

GET产生的URL地址能够被Bookmark，而POST不能够。

GET请求会被浏览器主动cache，而POST不会，除非手动设置。

GET请求只能进行url编码，而POST支持多种编码方式。

GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

GET只接受ASCII字符的参数的数据类型，而POST没有限制

那么，post那么好为何还用get？get效率高！。

8. session和cookie的区别

8.1 cookie

【cookie】cookie技术是客户端的解决方案，cookie就是由服务器发送给客户端的特殊信息

Cookie技术是客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，

而后客户端每次向服务器发送请求的时候都会带上这些特殊的信息

让咱们说得更具体一些：当用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的我的信息而且提交至服务器；

接着，服务器在向客户端回传相应的超文本的同时也会发回这些我的信息，固然这些信息并非存放在HTTP响应体（Response Body）中的，

而是存放于HTTP响应头（Response Header）

当客户端浏览器接收到来自服务器的响应以后，浏览器会将这些信息存放在一个统一的位置，

对于Windows操做系统而言，咱们能够从： [系统盘]:\Documents and Settings[用户名]\Cookies目录中找到存储的Cookie；

自此，客户端再向服务器发送请求的时候，都会把相应的Cookie再次发回至服务器。而此次，Cookie信息则存放在HTTP请求头（Request Header）了。

有了Cookie这样的技术实现，服务器在接收到来自客户端浏览器的请求以后，就可以经过分析存放于请求头的Cookie获得客户端特有的信息，从而动态生成与该客户端相对应的内容。

一般，咱们能够从不少网站的登陆界面中看到“请记住我”这样的选项，若是你勾选了它以后再登陆，那么在下一次访问该网站的时候就不须要进行重复而繁琐的登陆动做了，而这个功能就是经过Cookie实现的。

----每次请求客户端都会把cookies放在请求头请求过来

 

HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的链接就会关闭，再次交换数据须要创建新的链接。这就意味着服务器没法从链接上跟踪会话。

即用户A购买了一件商品放入购物车内，当再次购买商品时服务器已经没法判断该购买行为是属于用户A的会话仍是用户B的会话了。

要跟踪该会话，必须引入一种机制。

Cookie就是这样的一种机制。它能够弥补HTTP协议无状态的不足。在Session出现以前，基本上全部的网站都采用Cookie来跟踪会话。

因为HTTP是一种无状态的协议，服务器单从网络链接上无从知道客户身份。怎么办呢？

就给客户端们颁发一个通行证吧，每人一个，不管谁访问都必须携带本身通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工做原理。

Cookie其实是一小段的文本信息。客户端请求服务器，若是服务器须要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。

客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。

服务器检查该Cookie，以此来辨认用户状态。

服务器还能够根据须要修改Cookie的内容。

 8.2 session

除了使用Cookie，Web应用程序中还常用Session来记录客户端状态。

Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增长了服务器的存储压力。

8.2.1  什么是Session

Session是另外一种记录客户状态的机制，不一样的是Cookie保存在客户端浏览器中，而Session保存在服务器上。

客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。

客户端浏览器再次访问时只须要从该Session中查找该客户的状态就能够了。

若是说Cookie机制是经过检查客户身上的“通行证”来肯定客户身份的话，那么Session机制就是经过检查服务器上的“客户明细表”来确认客户身份。

Session至关于程序在服务器上创建的一份客户档案，客户来访的时候只须要查询客户档案表就能够了。

 

8.3 session和cookie的区别

【1】存放位置不一样：cookie数据存放在客户的浏览器上，session数据放在服务器上。

【2】存取方式不一样：cookie存放的是ascii字符串，session中能够存取任何类型的数据；

【3】cookie不是很安全，别人能够分析存放在本地的COOKIE并进行COOKIE欺骗
   考虑到安全应当使用session

【4】cookie会在客户端存放很长的时间；可是sessio依赖与session id，若是id为-1，若是关闭浏览器，则session会失效了；

【5】对服务器形成的压力不一样：session会在必定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
   考虑到减轻服务器性能方面，应当使用COOKIE。

【6】  将登录信息等重要信息存放为SESSION； 其余信息若是须要保留，能够放在COOKIE中

9.HTTPS

HTTP & HTTPS网络协议重点总结（基于SSL/TLS的握手、TCP/IP协议基础、加密学）

本文以总结的形式，先大致介绍TCP／IP协议总体组成，再择其应用层上的HTTP协议进行详细总结，继而拓展知识点讲解加密学，过渡到HTTPS协议的学习，除去网络知识必备掌握的三次握手、四次挥手，另需了解基于SSL/TLS的握手，也是重要的一个环节。

本文涉及到的知识点以下：

  • 网络基础TCP/IP
  • HTTP协议基础与重点
  • 加密与签名
  • HTTPS协议（基于SSL/TLS的握手）

（若想要详细了解TCP三次握手、四次挥手相关知识点，可看此篇博客： 
深刻浅出之 TCP协议（三次握手与四次挥手、超时重发、流量控制、拥塞控制、与UDP区别））

9.1 . 网络基础TCP/IP

在正式介绍HTTP网络知识以前，先追其根源—–TCP/IP协议族，一般使用的网络是在TCP/IP协议族的基础上运做的，而HTTP属于它内部的一个子集，因此先了解有关TCP/IP有关知识，为HTTP作铺垫。

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

1. TCP/IP协议分层管理

（1）协议（protocal）

计算机与网络相互通讯，双方必须基于相同的方法，例如由哪一方先发起通讯、使用哪一种语言进行通讯、如何结束通讯等都须要事先规定。不一样的硬件、OS之间的通讯都须要一种规则，就是协议（protocal）。

（2）TCP/IP协议定义

这里写图片描述

协议中存在各类内容，例如从电缆规格到IP地址的选定方法、双方创建通讯的顺序，以及web页面显示须要处理的步骤等。

以上这种与互联网相关联的协议集合起来总称为 TCP/IP（有的说法是TCP/IP是指TCP和IP这两种协议，还有一种说法是TCP/IP是在IP协议的通讯过程当中使用的协议族的统称）

（3）分层管理

TCP/IP协议族里重要的一点是分层，可分为：应用层、传输层、网络层、数据链路层。

其实层次化是有它的好处，若是互联网只有一个协议统筹，某个地方须要改动时须要将全部部分换掉，而分层以后只需替换变更层便可。每一层也只需考虑本身的任务便可。

  • 应用层：应用层决定了向用户提供应用服务时通讯的活动

TCP/IP协议族内预存了各种通用的应用服务，例如FTP（File Transfer Protocol文件传输协议）和DNS（Domain Name System域名系统）服务就是其中两类，HTTP协议也处于改层。

  • 传输层：传输层对上层应用层，提供处于网络链接中的两台计算机之间的数据传输。

在传输层有两个性质不一样的协议：TCP（Transmission Control Protocol传输控制协议）和UDP（User Data Protocol用户数据报协议）。

  • 网络层（网络互连层）：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了经过怎样的路径（传输路线）到达对方计算机，并把数据包传送给对方。

与对方计算机之间经过多台计算机或网络设备进行传输时，网络层所起做用就是在众多选项内选择一条传输路线。

  • 链路层（网络接口层）：用来处理链接网络的硬件部分。包括控制操做系统、硬件的设备驱动、网卡，以及光纤等物流可见部分。硬件上的范畴均在链路层的做用范围内。

2. TCP/IP通讯传输流

这里写图片描述

利用TCP/IP协议族进行网络通讯时，会经过分层顺序与对方进行通讯。发送端的顺序从应用层往下走，接收端则往应用层上走。

举个HTTP的例子：做为发送端的客户端在应用层（HTTP协议）发出一个想看某个Web页面的HTTP请求。

  • 为了传输方便，在传输层（TCP协议）把应用层处收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层。

  • 在网络层（IP协议），增长做为通讯目的地的MAC地址后转发给链路层。这样发送网络的通讯请求就准备彻底了。

  • 接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输层到应用层，才算真正接收到由客户端发送过来的HTTP请求。

这里写图片描述

发送端在层与层之间传输数据时，每通过一层时一定会被打上一个该层所属的首部信息。反之，接收端在层与层传输数据时，每通过一层时会把对应的首部消去。

这种包装数据信息的行为称为封装（encapsulate）

3. 与HTTP关系密切的协议：IP、TCP和DNS

（1）负责传输的IP协议

定义做用

  • 定义： IP（Internet Protocol）网际协议位于网络层。IP占据了TCP/IP协议族的“一半”，可见其重要性，切勿将IP同IP地址搞混，“IP”是一种协议的名称。

  • 做用：把各类数据包传送给对方。要保证确实传送到对方那里，需知足各种条件，其中两个重要的条件：（IP地址能够和MAC地址进行配对，IP地址可变换，但MAC地址基本上不会改变。）

    • IP地址：指明节点被分配的位置。
    • MAC地址（Media Access Control Address）：指网卡所属的固定地址。

使用ARP协议凭借MAC地址进行通信

IP间的通讯依赖MAC地址。在网络上，通讯的双方在同一局域网（LAN）内的状况不多，一般是通过多台计算机和网络设备中转才能链接到对方。

在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标。这时会采用ARP协议（Address Resolution Protocol），它是一种用以解析地址的协议，根据通讯方的IP地址就能够反查出对应的MAC地址。

没法全面掌握互联网中的传输情况

在到达通讯目标前的中转过程当中，那些计算机和路由器等网络设备只能获悉很粗略的传输路线。

这种机制称为路由选择（rounting），有点像快递送货，寄快递时把货物送到集散中心，便可知道是否肯收件，接着检查送达地址，明确下一站送达的集散中心，下一个集散中心再判断是否能送达目的地。（其中的中转过程没法掌握，因此没法掌握互联网中的细节。）

（2）确保可靠性的TCP协议

TCP位于传输层，提供可靠的字节流服务（Byte Stream Service）。

  • 字节流服务：为了方便传输，将大块数据分割以报文段（segment）为单位的数据包进行管理。
  • 可靠的传输服务：可以把数据准确可靠地传给对方。

TCP协议为了更容易传送大数据才把数据分割，并且TCP协议可以确认数据最终是否送达到对方。

确保数据能到达目标

为了准确无误地将数据送达目标处，TCP协议采用了三次握手（three-way handshaking）策略。

用TCP协议将数据包送出去后，TCP必定会向对方确认是否成功送达。

若在握手过程当中某个阶段莫名中断，TCP协议会再次以相同的顺序发送相同的顺序包。

握手过程

  • 定义：三次握手，是指创建一个TCP链接时，须要客户端和服务器总共发送3个包。
  • 目的：是链接服务器指定端口，创建TCP链接,并同步链接双方的序列号和确认号并交换 TCP 窗口大小信息

在socket编程中，客户端执行connect()时，将触发三次握手。

这里写图片描述

  • 第一次握手：创建链接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；

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

  • 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据。

（若想要详细了解TCP三次握手、四次挥手相关知识点，请看此篇博客： 
深刻浅出之 TCP协议（三次握手与四次挥手、超时重发、流量控制、拥塞控制、与UDP区别））

（3）负责域名解析的DNS服务

DNS（Domain Name System）服务是和HTTP协议同样位于应用层的协议，它提供域名到IP地址之间的解析服务。

计算机不只能够被赋予IP地址，也能够被赋予主机名和域名。

例如 www.baidu.com。用户常用这种方式来访问对方计算机，但要让计算机去理解名称就显得困难，所以DNS服务应运而生，

DNS协议提供经过域名查找IP地址，或逆向从IP地址反查域名的服务。

4. 各类协议与HTTP协议的关系

这张图是客户端向服务器请求资源时的过程，在HTTP通讯过程当中包含了IP协议、TCP协议、DNS服务，发挥着各自的做用，查看下图。

这里写图片描述

二. Http协议

1. 基本概念

（1）HTTP协议及特色

  • 协议：指计算机通讯网络中两台计算机之间进行通讯所必须共同遵照的规定或规则。

  • HTTP协议：超文本传输协议（HTTP）是一种通讯协议，它容许将超文本标记语言（HTML）文档从Web服务器传送到客户端的浏览器。

这里写图片描述

如上图，其实HTTP协议是基于TCP/IP协议来传递数据，从服务器端获取到数据，是C/S架构——客户端到服务端通讯的接口。浏览器做为HTTP协议下的客户端，经过URL发送请求到服务端，服务端作出响应将内容返回给浏览器显示，这就是一个基本的C/S架构的HTTP协议。

HTTP协议特色：

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

（2） Http 版本区别

这里写图片描述

（3）HTTP请求报文和响应报文

HTTP请求报文主要由请求行、请求头、空行、请求正文（GET方式无请求正文）4部分组成。

  • 请求行：由请求方法、URL和协议版本3部分组成。
  • 请求头：为请求报文添加一些信息，由“名／值”组成。
  • 空行：请求头的最后会有一个空行，表明请求头部结束，接下来为请求正文。此部分不可少。
  • 请求正文

HTTP响应报文主要由状态行、响应头、空行、响应正文4部分组成。

  • 状态行：由状态码、状态码描述和协议版本3部分组成。
  • 响应头：为响应报文添加一些信息，由“名／值”组成。
  • 空行：头的最后会有一个空行，表明响应头部结束，接下来为响应正文。此部分不可少。
  • 响应正文

（4） Http的请求方式总结

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

HEAD、GET、OPTIONS和TRACE是安全的方法，由于它们只从服务器得到资源而不对服务器作任何修改，可是前三个在用户端不安全，POST相对安全，但POST会影响服务器的资源。TRACE方法对于服务端盒用户端必定是安全的。

（5） 请求头信息

请求头 说明
User-Agent 中文名为用户代理，是Http协议中的一部分，它是一个特殊字符串头，是一种向访问网站提供你所使用的浏览器类型及版本、操做系统及版本、浏览器内核、等信息的标识
Referer 先前网页的地址，当前请求网页紧随其后,即来路
Cache-Control 指定请求和响应遵循的缓存机制
Connection 表示是否须要持久链接。（HTTP 1.1默认进行持久链接）
If-Match 只有请求内容与实体相匹配才有效
If-Modified-Since 若是请求的部分在指定时间以后被修改则请求成功，未被修改则返回304代码
If-None-Match 若是内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变

这里只介绍举例部分重要的请求响应头，关于更详细信息可看： 
http://tools.jb51.net/table/http_header

（6） 响应头信息

应答头 说明
Content-Encoding 文档的编码（Encode）方法。只有在解码以后才能够获得Content-Type头指定的内容类型。
Content-Type 表示后面的文档属于什么MIME类型。
Date 当前的GMT时间。你能够用setDateHeader来设置这个头以免转换时间格式的麻烦。
Expires 过时时间
Last-Modified 档的最后改动时间。客户能够经过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，不然返回一个304（Not Modified）状态。

. 
（7） 状态码信息

HTTP状态码分类

分类 描述
1** 信息，服务器收到请求，须要请求者继续执行操做
2** 成功，操做被成功接收并处理
3** 重定向，须要进一步的操做以完成请求
4** 客户端错误，请求包含语法错误或没法完成请求
5** 服务器错误，服务器在处理请求的过程当中发生了错误

较经常使用状态码

  • 200 - 请求成功
  • 301 - 资源（网页等）被永久转移到其它URL
  • 404 - 请求的资源（网页等）不存在
  • 500 - 内部服务器错误

2. Http请求方式Get和Post的区别

安全幂等性质

  • GET通常用于获取或者查询资源信息，这就意味着它是幂等的（对同一个URL的屡次请求返回一样的结果）和安全的（没有修改资源的状态）
  • POST通常用于更新资源信息，既不是安全，也非幂等。

参数存放位置

  • GET方法中，客户端把要发送的数据添加到URL后面（即把数据放到HTTP协议头中，GET是经过URL请求数据的），使用“？”链接，参数之间使用“&”链接。注意：HTTP协议中并无对URL长度进行限制，可是浏览器和服务器会对其限制！（面试中常常会问到URL长度限制问题，必定要明白协议中并未对此规定！）
  • POST是将须要传递的数据放到HTTP请求报文的消息体中（一样，协议未对此部分大小进行限制），不过传送的数据量比GET更大且安全性更高（若不对数据进行加密，可以使用抓包软件进行获取）。

浏览器缓存

  • GET请求的数据会被浏览器缓存起来，留下历史记录。
  • POST提交的数据不会。

3. 为何HTTP是无状态的？如何保持状态？

HTTP无状态：是指协议对于事务处理没有记忆能力，不能保存每次客户端提交的信息，即当服务器返回应答后，这次事务的全部消息会被丢掉。即便客户端发来一个新的相同的请求，服务器没法知道它是否与上次请求有联系。

举个例子：一个包含多个图片的网页浏览步骤：

  • 创建链接，客户端发送一个网页请求，服务端返回一个HTML页面（一个纯文本页面），关闭链接。
  • 浏览器解析HTML文件，遇到图片标记获得URL，此时客户端和服务器再创建链接，客户端发送一个图片请求，服务器返回图片应答，关闭链接。（涉及到无状态定义，对于服务器而言，即便是同一个客户端请求，无记忆能力没法识别）

优缺点

  • 优势：服务器不用为每一个客户端链接分配内存来记忆大量状态，也不用在客户端失去链接时去清除内存，节省服务器端资源。
  • 缺点： 若是后续处理须要前面的信息，客户端必须重传，可能致使每次链接传送的数据量增大。

解决办法

针对这些问题，能够采用会话跟踪技术，即把状态保存在服务器，只发送回一个标识符，浏览器在下次提交中把这个标识符发送过来，这样能够定位存储在服务器上的状态信息。技术有如下：

  • COOKIE
  • SESSION
  • URL重写
  • 做为隐藏域嵌入HTML表单中

4. cookie与session

（1）Cookie

定义

Cookie技术是客户端的解决方案，由服务器发送给客户端的特殊信息，存放在response的header中，这些信息以文本文件方式存放在客户端，由客户端每次向服务器发送请求时带上，此时是存放在request的header中。

以下图，Cookie的设置可分为如下几个步骤：

  • 客户端向服务端Request请求。
  • 服务器在response的header中设置Cookie，发送给客户端。
  • 客户端会将请求request和Cookie一块儿打包发送给服务端。
  • 服务端会根据Cookie判断将response返回给客户端。

由于HTTP协议“无状态”的特色，在请求完毕后会关闭链接，再次交换数据须要创建新的链接，没法跟踪会话。Cookie机制的引入正好弥补了HTTP协议“无状态”的缺陷。

这里写图片描述

工做原理

因为HTTP协议是“无状态”的，因此服务器没法从网络上获取用户的真实身份。

解决办法：此时客户端给服务端发一个“通行证”，它是一个惟一的标识，不管哪一个用户访问服务器须要带上此标识，这样服务器便可辨识用户，这也就是Cookie的原理—–我的身份标识。

总结

在客户端向服务端请求时，若服务器要记录该用户信息，就发送一个携带cookie的response，客户端会保留此cookie，当客户端须要再次请求时，将请求URL和Cookie信息一同打包发送给服务端，此时服务器便可根据cookie辨认状态再作出响应（也可修改）。

总而言之，Cookie就是用户识别标志，保存在客户端！

这里写图片描述

（2）session

定义

Session是另外一种记录客户状态的机制，不一样的是Cookie保存在客户端浏览器中，而Session保存在服务器行。客户端浏览器访问的时候，服务器把客户端信息以某种形式记录在服务器上。

注意：当客户端浏览器再次请求服务器时是不须要携带信息的，在服务器上已有记录。

工做原理

  • 在服务端运行程序时建立Session
  • 在建立Session的同时，服务器会为该Session生成惟一的Session ID
  • 在Session被建立后，能够调用相关方法往Session中添加内容，注意发送到客户端的只有Session ID
  • 当客户端再次发送请求时，会将Session ID带上，服务器接受到请求以后就会依据ID确认用户身份，找到相应的Session。

（3）二者的区别

  • 存放位置不一样 
    • Cookie：保存在客户端；
    • Session：保存在服务端；
  • 存取方式不一样 
    • Cookie：只能保存ASCII码字符串；
    • Session：可保存任何数据；
  • 安全性（隐私策略）不一样 
    • Cookie：因为它存放在浏览器中，因此对客户端是可见的，客户端的程序有可能修改内容；
    • Session：存放在服务端，不存在敏感信息泄露；
  • 有效期不一样 
    • Cookie：客户端通常设置有效期较长，这样可保存较长时间；
    • Session：设置成-1后，在用户关闭浏览器后，session就会失效；
  • 对服务器形成的压力不一样 
    • Cookie：保存在客户端，不占用服务器内存；
    • Session：因为它存放在服务端，多个用户并发访问服务器时，会产生多个session，十分消耗内存；

5. HTTP的短链接和长链接的原理

在HTTP1.0中默认采用的是短链接，即浏览器和服务器每进行一次HTTP操做须要进行一次链接，任务结束时中断。若客户端访问的某个HTML或其余类型的Web中又包含其余Web资源，例如JS文件、图像文件、CSS文件，那么每次遇到以一个Web资源都会创建一个HTTP会话，进行三次握手，十分耗费资源。所以，经过在Request中增长“Connection：keep-alive”可支持长链接。

当HTTP采用长链接时的数据交互流程以下：

  • 客户端发出request，其中该版本号为1.0，而且在request中包含了一个header：“Connection：keep-alive”。
  • 服务器收到该请求的长链接后，将会在response加上“Connection：keep-alive”，同时不会关闭已创建的TCP链接。
  • 同时，客户端收到response中的header，发现是一个长链接，一样不会关闭已创建的TCP链接。

在HTTP1.1起，默认使用长链接，来保持链接特性，即在请求头和响应头中默认加入“Connection：keep-alive” 。HTTP长链接利用同一个TCP链接处理多个HTTP请求和响应。

Keep-Alive不会永久保持链接，有一个保持时间，能够在不一样的服务器中设定时间，实现长链接要求客户端和服务器都支持长链接。

三. 加密与签名

在讲解HTTPS以前须要了解一些预备知识，即加密与签名。

1. 密码学

若是不对传输数据进行加密，很容易被第三方窃取或篡改，因此加密是保护数据的措施。最多见的就是对数据进行MD5加密，获取数据后再将其解密。

（1）组成

所以，加密包含算法和密钥这两个元素，二者结合会使原有数据加密为明文，而加密分为如下两个部分：

  • 对称加密

    • 定义：加密数据用的密钥，跟解密数据用的密钥是同样的。
    • 优点：此定义决定了它的特色：加密和解密过程效率很是高
    • 劣势：可是缺点也很明显，即双方执同一个密钥，必需要确保密钥的安全性，带来的技术成本很高。

  • 不对称加密：其中含有两个密钥，一个是一方保管的私有密钥，另外一个是双方公有的公有密钥。这种方式决定了发送秘文的一方先获取对方的公有密钥，经过算法进行处理，对方收到加密数据后，使用本身的私有密钥进行解密。

（2）数字证书

定义：数字证书就是互联网通信中标志通信各方身份的一串数字。

产生的缘由：请求方如何肯定它想要的公钥未通过第三方篡改，必定是从目标主机而来的？此时须要一个权威机构来发放密钥，来解决数字证书的安全问题。

颁发过程：首先用户要产生本身的密钥，和公有密钥一块儿交给认证中心，认证中心核实身份以后会将确认中心发给用户，会颁发一个数字证书，含有密钥信息。

2. 密钥

（1）定义

密钥是一种参数，它是在使用密码cipher算法过程当中输入的参数。同一个明文在相同的密码算法和不一样的密钥计算下会产生不一样的密文。密钥才是决定加密数据是否安全的重要参数。

（2）明文到密文的加密过程

这里写图片描述

（3）密钥组成

  • 对称密钥

    • 定义：又称为共享密钥加密，对称密钥在加密、解密过程当中使用的密钥相同，常见对称加密算法有：DES、3DES、AES、RC五、RC6。
    • 优势：计算速度快；
    • 缺点：密钥须要在通信的两端共享，存在安全性问题；

  • 不对称密钥

    • 定义：又称为公开密钥加密。服务端会生成一对密钥，一个私钥保存在服务端，仅本身知道，另外一个公钥能够自由发布供任何人使用。常见的是RSA算法。
    • 优势：无需在客户端和服务端之间共享密钥，只要私钥不发给任何用户，即便公钥在网络上被截获，也没法破解数据。

（4）RSA加密简单过程

  • 服务端生成配对的公钥和私钥；
  • 密钥保存在服务端，公钥发送给客户端；
  • 客户端使用公钥加密明文传输给服务端；
  • 服务端使用私钥解密密文获得明文。

3. 数字签名

首先思考一个问题：浏览器和服务器直接传输数据时，有可能被黑客篡改，如何保证数据安全性？须要引出此部分核心——数字签名。

（1）定义

数字签名是用于验证传输内容是不是真实服务器发送的数据，是否被篡改过，主要验证这两件事，是非对称加密的一种应用场景，但它是反过来用秘钥加密，经过与之配对的公钥解密。

（2）加密过程

这里写图片描述

  • 第一步：查看上图，服务端将报文进行哈希处理后生成摘要信息，摘要信息使用私钥加密以后才会生成签名，而服务端将签名连同报文一块儿发送给客户端。

这里写图片描述

  • 第二步：查看上图，客户端接收到数据后，把签名提取出来用公钥解密，若是能正常将Digest2 解密出来，便可确认是对方发的。
  • 第三步：客户端把报文Text提取出来作一样的哈希出来，获得的摘要信息Digest1，再与以前解密出来的Digest2 对比。

四. HTTPS（TLS与SSL握手）

1. HTTP的缺点

在了解HTTP特色以后，不可忽视的是它的不足之处：

  • 通讯使用明文（不加密），内容可能被监听；
  • 不验证通讯方的身份，有可能遭遇假装；
  • 没法证实报文的完整性，有可能已遭篡改；

以上三个问题不只在HTTP上出现，其它未加密的协议也存在这些问题。除此以外，还有其它的缺点。

（1）通讯使用明文可能会被窃听

因为HTTP自己不具有加密功能，因此没法作到对通讯总体（使用HTTP协议通讯的请求和响应的内容）进行加密，即HTTP报文使用明文的方式发送。

TCP/IP是可能被窃听的网络

按照TCP/IP 协议族的工做机制，通讯内容在全部的通讯线路上都有可能遭到窥视。

加密处理防止被窃听

防止窃听保护信息的几种对策中，最为普及的就是加密技术，加密对象有如下几个：

  • 通讯的加密： HTTP协议中没有加密机制，能够经过SSL（Secure Socket Layer安全套接层）或TLS（Transport Layer Security安全传输层协议）的组合使用，加密HTTP的通讯内容。用SSL创建安全通讯线路以后，就能够在这条线路上进行HTTP通讯。与SSL组合使用的HTTP被称为HTTPS。

  • 内容的加密：对HTTP协议传输内容自己加密。客户端须要对HTTP报文进行加密处理后再发送请求。为了作到有效的内容加密，前提是客户端和服务器同时具有加密和解密机制。（该方法不一样于SSL或TLS将整个通讯线路加密处理，因此内容有篡改的风险，后续讲解）

（2）不验证通讯方的身份可能遭遇假装

在HTTP协议通讯时，因为不存在确认通讯方的处理步骤，任何人均可以发起请求，服务器只有收到请求，不管是谁都返回响应，所以存在如下隐患：

  • 没法肯定请求发送至目标的Web服务器是不是真实返回响应的服务器。（多是假装的）
  • 没法肯定响应返回到客户端是不是真实接收响应的客户端。（多是假装的）
  • 没法肯定正在通讯的对方是否具有访问权限。由于某些Web服务器保存重要信息，只想发给特定用户通讯的权限。
  • 没法断定请求出处。
  • 即便是无心义的请求也会照单全收。没法阻止海量请求下的DoS攻击。

查明对手的证书

虽然HTTP协议没法肯定通讯方，可是使用SSL能够。SSL不只提供加密处理，还使用了一种被称为证书的手段，可用于肯定方。

经过使用证书，来证实通讯方就是意料中的服务器，这对使用者我的来说减小了信息泄露的危险。另外客户端持有证书便可完成我的身份验证，可用于Web认证环节。

（3）没法证实报文完整性，可能已遭篡改

因为HTTP协议没法证实通讯报文的完整性，即便请求或响应内容遭到篡改，也没有办法获悉。

像这样，请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack）

如何防止篡改

虽然有使用HTTP协议肯定报文完整性的方法，事实上并不可靠，经常使用的是MD5（单向函数生成的散列值）和SHA-1等散列值校验方法，及用来确认文件的数字签名方法。惋惜的是若是MD5自己被改写，用户没有办法意识到。

为了有效防止以上这些弊端，须要使用到HTTPS。SSL提供认证和加密处理及摘要功能。仅靠HTTP确保完整性是很是困难的，所以经过和其余协议组合来实现此目标。

2. HTTPS = HTTP + 加密 + 认证 + 完整性保护

（1）定义

HTTPS并不是是应用层的一种新协议，只是HTTP通讯接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。经过在TCP和HTTP之间加入TLS来加密，由此保证数据传输的安全性。HTTPS就是身披SSL协议这串外壳的HTTP。

（2）SSL/TLS协议

SSL协议是一种安全传输协议，TLS是SSL v3.0的升级版。

（3）HTTPS层次图

查看HTTPS层次图，最底层是NetWork，依次往上是网络层、传输层、应用层。

这里写图片描述

传输层上面夹着TLS层，它就是安全传输协议在现实中的应用版，其中最上方的3个绿色小方框组成了TLS协议。上图相似于TCP/IP模型，只是多了一层TLS层，用来加密数据。

（4）HTTPS架构图

查看HTTPS架构图，其实HTTPS协议就是在HTTP基础上加上了加密、验证以及数据的保护。在使用HTTPS通讯时，使用的是 https://

（注意：HTTPS并不是是新协议，他只是HTTP通讯接口中加了一个SSL协议）

在HTTPS通讯时会先和SSL层创建通讯，而后SSL层再和传输层中的TCP通讯。因此HTTPS就是披了一层SSL外壳的HTTP协议

这里写图片描述

（5）HTTPS传输速度

SSL的慢可归于如下两点：一是通讯慢，一是因为大量消耗CPU及内存等资源，致使处理速度变慢。

  • 通讯慢：同HTTP协议相比，网络负载会变慢，由于除去TCP链接、HTTP请求与响应外，还必须处理SSL、TSL通讯，致使通讯量的增长。
  • SSL必须进行加密处理：在服务器端和客户端都要经过加密、解密进行数据的安全处理，所以从结果而言，比起HTTP会更多地消耗服务器和客户端的硬件资源，致使负载加强。

综合以上因素，只有在处理敏感信息时才使用HTTPS加密通讯。

3. TLS与SSL握手过程

这里写图片描述

查看上图，TLS与SSL握手过程能够总结如下5个步骤：

（1）客户端发起请求

首先客户端会将它支持的协议版本、加密压缩算法，并生成一个随机数（握手过程的第一个随机数）一块儿传送给服务端。注意：此随机数与后续服务端产生的随机数会组成密钥。

（2）服务器回应

当服务端收到客户端 hello的请求后，会肯定加密的协议算法，也会生成本身的一个随机数（握手过程的第二个随机数），连同证书一块儿发送给客户端。注意，至此客户端和服务端都拥有了两个随机数（Random1+ Random2），这两个随机数会在后续生成对称秘钥时用到。

（3）客户端验证证书

当客户端再次回应时，首先对服务端发来的证书进行验证，验证完毕后会再次产生一个随机数（握手过程的第三个随机数），此随机数是使用证书中公钥加密的，通知服务端编码已改变、握手结束。

（4）生成密钥

服务端接收到密钥以后，用私钥对这加密的数据进行解密并验证，验证完毕后向客户端发出通知确认编码改变、握手结束。

（5）客户端发送数据

客户端收到服务端发来的通知确认后，能够和服务端进行HTTPS安全的消息通信了。

注意

因为SSL协议在握手阶段使用的是非对称加密，通常是RSA加密算法，因此需知随机数是不能随意破解的，它是安全性的保证。

4. 再论TLS与SSL握手过程

以上第3点对TLS与SSL握手过程的总结适合新手初次学习，而此部分就正式地去介绍其细节，查看如下时序图：

这里写图片描述

(1)client_hello

客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息：

  • 支持的最高TSL协议版本version；
  • 客户端支持的加密套件 cipher suites 列表， 每一个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、
  • 密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验)；
  • 支持的压缩算法；
  • 扩展字段 extensions；
  • 随机数 random_C（此过程的第一个随机数），用于后续的密钥的生成；

(2)server_hello + server_certificate + sever_hello_done

  • server_hello：服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S（此过程的第二个随机数） 等，其中随机数用于后续的密钥协商;
  • server_certificates： 服务器端配置对应的证书链，用于身份验证与密钥交换;
  • server_hello_done：通知客户端 server_hello 信息发送结束;

(3)证书校验

客户端验证证书的合法性，若是验证经过才会进行后续通讯，不然根据错误状况不一样作出提示和操做，合法性验证包括以下：

  • 证书链的可信性 trusted certificate path，方法如前文所述;
  • 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不一样的客户端行为会不一样;
  • 有效期 expiry date，证书是否在有效时间范围;
  • 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析;

(4)client_key_exchange + change_cipher_spec + encrypted_handshake_message

  • client_key_exchange：合法性验证经过以后，客户端计算产生随机数字 Pre-master（此过程的第三个随机数），并用证书公钥加密，发送给服务器。

此时客户端已经获取所有的计算协商密钥须要的信息：两个明文随机数 random_C 和 random_S 与本身计算产生的 Pre-master，计算获得协商密钥。

  • change_cipher_spec：客户端通知服务器后续的通讯都采用协商的通讯密钥和加密算法进行加密通讯。

  • encrypted_handshake_message：，结合以前全部通讯参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，而后发送给服务器用于数据与握手验证。

(5) change_cipher_spec + encrypted_handshake_message

  • 服务器用私钥解密加密的 Pre-master 数据，基于以前交换的两个明文随机数 random_C 和 random_S，计算获得协商密钥
enc_key=Fuc(random_C, random_S, Pre-Master)
  • 1

  • 计算以前全部接收信息的 hash 值，而后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性。

  • change_cipher_spec： 验证经过以后，服务器一样发送 change_cipher_spec 以告知客户端后续的通讯都采用协商的密钥与算法进行加密通讯。

  • encrypted_handshake_message： 服务器也结合全部当前的通讯参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端。

(6)握手结束

客户端计算全部接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证经过则握手完成。

(7)加密通讯

开始使用协商密钥与算法进行加密通讯。

注意：

服务器也能够要求验证客户端，即双向认证，能够在过程2要发送 client_certificate_request 信息，客户端在过程4中先发送 client_certificate与certificate_verify_message 信息，证书的验证方式基本相同，certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通讯信息获得数据，服务器能够采用对应的公钥解密并验证。

后续相关知识还有：为了加快创建握手的速度，减小协议带来的性能下降和资源消耗(具体分析在后文)，TLS 协议有两类会话缓存机制：会话标识 session ID 与会话记录 session ticket。可查看如下连接。

此小节是借鉴于TLS/SSL握手过程，推荐查看。

5. 总结

HTTPS实际上就是在TCP层与HTTP层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书等技术进行客户端与服务器的数据加密传输，最终达到保证整个通讯的安全性。

 10.tcp/ip模型

 

互联网协议按照功能不一样分为osi七层或tcp/ip五层或tcp/ip四层

每层运行常见物理设备


各层网络协议的做用

  • 物理层：链接两台主机之间的物理介质，单纯的01传输电信号
  • 数据链路层：数据链路层规定电信号的分组方式，使用广播的方式在子网络中经过Mac地址的匹配，实现不一样电脑上的数据传输
  • 网络层：经过arp协议，使用ip来区分不一样的计算机是否属于同一个子网络，再经过广播的方式在子网络中经过Mac地址的匹配，实现不一样电脑上的数据传输
  • 传输层：创建一个端口到另外一个端口的通讯（TPC/IP协议）
  • 应用层：规定应用程序的数据格式（HTTP协议）

 【转载】

1、概述

1.1 五层模型

互联网的实现，分红好几层。每一层都有本身的功能，就像建筑物同样，每一层都靠下一层支持。

用户接触到的，只是最上面的一层，根本没有感受到下面的层。要理解互联网，必须从最下层开始，自下而上理解每一层的功能。

如何分层有不一样的模型，有的模型分七层，有的分四层。我以为，把互联网分红五层，比较容易解释。

如上图所示，最底下的一层叫作"实体层"（Physical Layer），最上面的一层叫作"应用层"（Application Layer），中间的三层（自下而上）分别是"连接层"（Link Layer）、"网络层"（Network Layer）和"传输层"（Transport Layer）。越下面的层，越靠近硬件；越上面的层，越靠近用户。

它们叫什么名字，其实并不重要。只须要知道，互联网分红若干层就能够了。

1.2 层与协议

每一层都是为了完成一种功能。为了实现这些功能，就须要你们都遵照共同的规则。

你们都遵照的规则，就叫作"协议"（protocol）。

互联网的每一层，都定义了不少协议。这些协议的总称，就叫作"互联网协议"（Internet Protocol Suite）。它们是互联网的核心，下面介绍每一层的功能，主要就是介绍每一层的主要协议。

2、实体层

咱们从最底下的一层开始。

电脑要组网，第一件事要干什么？固然是先把电脑连起来，能够用光缆、电缆、双绞线、无线电波等方式。

这就叫作"实体层"，它就是把电脑链接起来的物理手段。它主要规定了网络的一些电气特性，做用是负责传送0和1的电信号。

3、连接层

3.1 定义

单纯的0和1没有任何意义，必须规定解读方式：多少个电信号算一组？每一个信号位有何意义？

这就是"连接层"的功能，它在"实体层"的上方，肯定了0和1的分组方式。

3.2 以太网协议

早期的时候，每家公司都有本身的电信号分组方式。逐渐地，一种叫作"以太网"（Ethernet）的协议，占据了主导地位。

以太网规定，一组电信号构成一个数据包，叫作"帧"（Frame）。每一帧分红两个部分：标头（Head）和数据（Data）。

"标头"包含数据包的一些说明项，好比发送者、接受者、数据类型等等；"数据"则是数据包的具体内容。

"标头"的长度，固定为18字节。"数据"的长度，最短为46字节，最长为1500字节。所以，整个"帧"最短为64字节，最长为1518字节。若是数据很长，就必须分割成多个帧进行发送。

3.3 MAC地址

上面提到，以太网数据包的"标头"，包含了发送者和接受者的信息。那么，发送者和接受者是如何标识呢？

以太网规定，连入网络的全部设备，都必须具备"网卡"接口。数据包必须是从一块网卡，传送到另外一块网卡。网卡的地址，就是数据包的发送地址和接收地址，这叫作MAC地址。

每块网卡出厂的时候，都有一个全世界独一无二的MAC地址，长度是48个二进制位，一般用12个十六进制数表示。

前6个十六进制数是厂商编号，后6个是该厂商的网卡流水号。有了MAC地址，就能够定位网卡和数据包的路径了。

3.4 广播

定义地址只是第一步，后面还有更多的步骤。

首先，一块网卡怎么会知道另外一块网卡的MAC地址？

回答是有一种ARP协议，能够解决这个问题。这个留到后面介绍，这里只须要知道，以太网数据包必须知道接收方的MAC地址，而后才能发送。

其次，就算有了MAC地址，系统怎样才能把数据包准确送到接收方？

回答是以太网采用了一种很"原始"的方式，它不是把数据包准确送到接收方，而是向本网络内全部计算机发送，让每台计算机本身判断，是否为接收方。

上图中，1号计算机向2号计算机发送一个数据包，同一个子网络的3号、4号、5号计算机都会收到这个包。它们读取这个包的"标头"，找到接收方的MAC地址，而后与自身的MAC地址相比较，若是二者相同，就接受这个包，作进一步处理，不然就丢弃这个包。这种发送方式就叫作"广播"（broadcasting）。

有了数据包的定义、网卡的MAC地址、广播的发送方式，"连接层"就能够在多台计算机之间传送数据了。

4、网络层

4.1 网络层的由来

以太网协议，依靠MAC地址发送数据。理论上，单单依靠MAC地址，上海的网卡就能够找到洛杉矶的网卡了，技术上是能够实现的。

可是，这样作有一个重大的缺点。以太网采用广播方式发送数据包，全部成员人手一"包"，不只效率低，并且局限在发送者所在的子网络。也就是说，若是两台计算机不在同一个子网络，广播是传不过去的。这种设计是合理的，不然互联网上每一台计算机都会收到全部包，那会引发灾难。

互联网是无数子网络共同组成的一个巨型网络，很像想象的电脑会在同一个子网络，这几乎是不可能的。

所以，必须找到一种方法，可以区分哪些MAC地址属于同一个子网络，哪些不是。若是是同一个子网络，就采用广播方式发送，不然就采用"路由"方式发送。（"路由"的意思，就是指如何向不一样的子网络分发数据包，这是一个很大的主题，本文不涉及。）遗憾的是，MAC地址自己没法作到这一点。它只与厂商有关，与所处网络无关。

这就致使了"网络层"的诞生。它的做用是引进一套新的地址，使得咱们可以区分不一样的计算机是否属于同一个子网络。这套地址就叫作"网络地址"，简称"网址"。

因而，"网络层"出现之后，每台计算机有了两种地址，一种是MAC地址，另外一种是网络地址。两种地址之间没有任何联系，MAC地址是绑定在网卡上的，网络地址则是管理员分配的，它们只是随机组合在一块儿。

网络地址帮助咱们肯定计算机所在的子网络，MAC地址则将数据包送到该子网络中的目标网卡。所以，从逻辑上能够推断，一定是先处理网络地址，而后再处理MAC地址。

4.2 IP协议

规定网络地址的协议，叫作IP协议。它所定义的地址，就被称为IP地址。

目前，普遍采用的是IP协议第四版，简称IPv4。这个版本规定，网络地址由32个二进制位组成。

习惯上，咱们用分红四段的十进制数表示IP地址，从0.0.0.0一直到255.255.255.255。

互联网上的每一台计算机，都会分配到一个IP地址。这个地址分红两个部分，前一部分表明网络，后一部分表明主机。好比，IP地址192.168.0.1，这是一个32位的地址，假定它的网络部分是前24位（192.168.0.1），那么主机部分就是后8位（最后的那个1）。处于同一个子网络的电脑，它们IP地址的网络部分一定是相同的，也就是说192.168.0.25应该与192.168.0.1处在同一个子网络。

可是，问题在于单单从IP地址，咱们没法判断网络部分。仍是以192.168.0.1为例，它的网络部分，究竟是前24位，仍是前16位，甚至前28位，从IP地址上是看不出来的。

那么，怎样才能从IP地址，判断两台计算机是否属于同一个子网络呢？这就要用到另外一个参数"子网掩码"（subnet mask）。

所谓"子网掩码"，就是表示子网络特征的一个参数。它在形式上等同于IP地址，也是一个32位二进制数字，它的网络部分所有为1，主机部分所有为0。好比，IP地址192.168.0.1，若是已知网络部分是前24位，主机部分是后8位，那么子网络掩码就是11111111.11111111.11111111.00000000，写成十进制就是255.255.255.0。

知道"子网掩码"，咱们就能判断，任意两个IP地址是否处在同一个子网络。方法是将两个IP地址与子网掩码分别进行AND运算（两个数位都为1，运算结果为1，不然为0），而后比较结果是否相同，若是是的话，就代表它们在同一个子网络中，不然就不是。

好比，已知IP地址192.168.0.1和192.168.0.1的子网掩码都是255.255.255.0，请问它们是否在同一个子网络？二者与子网掩码分别进行AND运算，结果都是192.168.0.0，所以它们在同一个子网络。

总结一下，IP协议的做用主要有两个，一个是为每一台计算机分配IP地址，另外一个是肯定哪些地址在同一个子网络。

4.3 IP数据包

根据IP协议发送的数据，就叫作IP数据包。不难想象，其中一定包括IP地址信息。

可是前面说过，以太网数据包只包含MAC地址，并无IP地址的栏位。那么是否须要修改数据定义，再添加一个栏位呢？

回答是不须要，咱们能够把IP数据包直接放进以太网数据包的"数据"部分，所以彻底不用修改以太网的规格。这就是互联网分层结构的好处：上层的变更彻底不涉及下层的结构。

具体来讲，IP数据包也分为"标头"和"数据"两个部分。

"标头"部分主要包括版本、长度、IP地址等信息，"数据"部分则是IP数据包的具体内容。它放进以太网数据包后，以太网数据包就变成了下面这样。

IP数据包的"标头"部分的长度为20到60字节，整个数据包的总长度最大为65,535字节。所以，理论上，一个IP数据包的"数据"部分，最长为65,515字节。前面说过，以太网数据包的"数据"部分，最长只有1500字节。所以，若是IP数据包超过了1500字节，它就须要分割成几个以太网数据包，分开发送了。

4.4 ARP协议

关于"网络层"，还有最后一点须要说明。

由于IP数据包是放在以太网数据包里发送的，因此咱们必须同时知道两个地址，一个是对方的MAC地址，另外一个是对方的IP地址。一般状况下，对方的IP地址是已知的（后文会解释），可是咱们不知道它的MAC地址。

因此，咱们须要一种机制，可以从IP地址获得MAC地址。

这里又能够分红两种状况。第一种状况，若是两台主机不在同一个子网络，那么事实上没有办法获得对方的MAC地址，只能把数据包传送到两个子网络链接处的"网关"（gateway），让网关去处理。

第二种状况，若是两台主机在同一个子网络，那么咱们能够用ARP协议，获得对方的MAC地址。ARP协议也是发出一个数据包（包含在以太网数据包中），其中包含它所要查询主机的IP地址，在对方的MAC地址这一栏，填的是FF:FF:FF:FF:FF:FF，表示这是一个"广播"地址。它所在子网络的每一台主机，都会收到这个数据包，从中取出IP地址，与自身的IP地址进行比较。若是二者相同，都作出回复，向对方报告本身的MAC地址，不然就丢弃这个包。

总之，有了ARP协议以后，咱们就能够获得同一个子网络内的主机MAC地址，能够把数据包发送到任意一台主机之上了。

5、传输层

5.1 传输层的由来

有了MAC地址和IP地址，咱们已经能够在互联网上任意两台主机上创建通讯。

接下来的问题是，同一台主机上有许多程序都须要用到网络，好比，你一边浏览网页，一边与朋友在线聊天。当一个数据包从互联网上发来的时候，你怎么知道，它是表示网页的内容，仍是表示在线聊天的内容？

也就是说，咱们还须要一个参数，表示这个数据包到底供哪一个程序（进程）使用。这个参数就叫作"端口"（port），它实际上是每个使用网卡的程序的编号。每一个数据包都发到主机的特定端口，因此不一样的程序就能取到本身所须要的数据。

"端口"是0到65535之间的一个整数，正好16个二进制位。0到1023的端口被系统占用，用户只能选用大于1023的端口。无论是浏览网页仍是在线聊天，应用程序会随机选用一个端口，而后与服务器的相应端口联系。

"传输层"的功能，就是创建"端口到端口"的通讯。相比之下，"网络层"的功能是创建"主机到主机"的通讯。只要肯定主机和端口，咱们就能实现程序之间的交流。所以，Unix系统就把主机+端口，叫作"套接字"（socket）。有了它，就能够进行网络应用程序开发了。

5.2 UDP协议

如今，咱们必须在数据包中加入端口信息，这就须要新的协议。最简单的实现叫作UDP协议，它的格式几乎就是在数据前面，加上端口号。

UDP数据包，也是由"标头"和"数据"两部分组成。

"标头"部分主要定义了发出端口和接收端口，"数据"部分就是具体的内容。而后，把整个UDP数据包放入IP数据包的"数据"部分，而前面说过，IP数据包又是放在以太网数据包之中的，因此整个以太网数据包如今变成了下面这样：

UDP数据包很是简单，"标头"部分一共只有8个字节，总长度不超过65,535字节，正好放进一个IP数据包。

5.3 TCP协议

UDP协议的优势是比较简单，容易实现，可是缺点是可靠性较差，一旦数据包发出，没法知道对方是否收到。

为了解决这个问题，提升网络可靠性，TCP协议就诞生了。这个协议很是复杂，但能够近似认为，它就是有确认机制的UDP协议，每发出一个数据包都要求确认。若是有一个数据包遗失，就收不到确认，发出方就知道有必要重发这个数据包了。

所以，TCP协议可以确保数据不会遗失。它的缺点是过程复杂、实现困难、消耗较多的资源。

TCP数据包和UDP数据包同样，都是内嵌在IP数据包的"数据"部分。TCP数据包没有长度限制，理论上能够无限长，可是为了保证网络的效率，一般TCP数据包的长度不会超过IP数据包的长度，以确保单个TCP数据包没必要再分割。

6、应用层

应用程序收到"传输层"的数据，接下来就要进行解读。因为互联网是开放架构，数据来源五花八门，必须事先规定好格式，不然根本没法解读。

"应用层"的做用，就是规定应用程序的数据格式。

举例来讲，TCP协议能够为各类各样的程序传递数据，好比Email、WWW、FTP等等。那么，必须有不一样协议规定电子邮件、网页、FTP数据的格式，这些应用程序协议就构成了"应用层"。

这是最高的一层，直接面对用户。它的数据就放在TCP数据包的"数据"部分。所以，如今的以太网的数据包就变成下面这样。

至此，整个互联网的五层结构，自下而上所有讲完了。这是从系统的角度，解释互联网是如何构成的。下一篇，我反过来，从用户的角度，自上而下看看这个结构是如何发挥做用，完成一次网络数据交换的。

11.DNS

【参考博客】https://blog.csdn.net/root_robot/article/details/53872812

什么是DNS？

DNS( Domain Name System)是“域名系统”的英文缩写，是一种组织成域层次结构的计算机和网络服务命名系统，它用于TCP/IP网络，它所提供的服务是用来将主机名和域名转换为IP地址的工做。你能够把它想象成一本巨大的电话本。
举例来讲，若是你要访问域名www.baidu.,com，首先要经过DNS查出它的IP地址是151.101.129.69。
若是你不清楚为何必定要查出IP地址，才能进行网络通讯，建议先阅读我写的《互联网协议入门》。

DNS就是这样的一位“翻译官”，它的基本工做原理可用下图来表示：

 

DNS服务的工做过程

当 DNS 客户机须要查询程序中使用的名称时，它会查询本地DNS 服务器来解析该名称。客户机发送的每条查询消息都包括3条信息，以指定服务器应回答的问题。
● 指定的 DNS 域名，表示为彻底合格的域名 (FQDN) 。
● 指定的查询类型，它可根据类型指定资源记录，或做为查询操做的专门类型。
● DNS域名的指定类别。
对于DNS 服务器，它始终应指定为 Internet 类别。例如，指定的名称能够是计算机的彻底合格的域名，如im.qq.com，而且指定的查询类型用于经过该名称搜索地址资源记录。
DNS 查询以各类不一样的方式进行解析。客户机有时也可经过使用从之前查询得到的缓存信息就地应答查询。DNS 服务器可以使用其自身的资源记录信息缓存来应答查询，也可表明请求客户机来查询或联系其余 DNS 服务器，以彻底解析该名称，并随后将应答返回至客户机。这个过程称为递归。
另外，客户机本身也可尝试联系其余的 DNS 服务器来解析名称。若是客户机这么作，它会使用基于服务器应答的独立和附加的查询，该过程称做迭代，即DNS服务器之间的交互查询就是迭代查询。

DNS的查询过程以下所示：

一、在浏览器中输入www . qq .com 域名，操做系统会先检查本身本地的hosts文件是否有这个网址映射关系，若是有，就先调用这个IP地址映射，完成域名解析。
二、若是hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，若是有，直接返回，完成域名解析。
三、若是hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/ip参数中设置的首选DNS服务器，在此咱们叫它本地DNS服务器，此服务器收到查询时，若是要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具备权威性。
四、若是要查询的域名，不禁本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具备权威性。
五、若是本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，若是未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来受权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，若是本身没法解析，它就会找一个管理.com域的下一级DNS服务器地址(http://qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找http://qq.com域服务器，重复上面的动做，进行查询，直至找到www . qq .com主机。
六、若是用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器若是不能解析，或找根DNS或把转请求转至上上级，以此循环。无论是本地DNS服务器用是是转发，仍是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间就是的交互查询就是迭代查询。

12.https算法相关

密钥(key)

密钥是一种参数，它是在使用密码（cipher）算法过程当中输入的参数。同一个明文在相同的密码算法和不一样的密钥计算下会产生不一样的密文。
不少知名的密码算法都是公开的，密钥才是决定密文是否安全的重要参数，一般密钥越长，破解的难度越大，好比一个8位的密钥最多有256种状况，使用穷举法，能很是轻易的破解，
知名的DES算法使用56位的密钥，目前已经不是一种安全的加密算法了，主要仍是由于56位的密钥过短，在数小时内就能够被破解。密钥分为对称密钥与非对称密钥。

明文/密文

明文（plaintext）是加密以前的原始数据，密文是经过密码（cipher）运算后获得的结果成为密文（ciphertext）

对称密钥

对称密钥（Symmetric-key algorithm）又称为共享密钥加密，对称密钥在加密和解密的过程当中使用的密钥是相同的，
常见的对称加密算法有DES、3DES、AES、RC五、RC6。
对称密钥的优势是计算速度快，可是他也有缺点，密钥须要在通信的两端共享，让彼此知道密钥是什么对方才能正确解密，
若是全部客户端都共享同一个密钥，那么这个密钥就像万能钥匙同样，能够凭借一个密钥破解全部人的密文了，若是每一个客户端与服务端单独维护一个密钥，那么服务端须要管理的密钥将是成千上万，这会给服务端带来噩梦

非对称密钥

非对称密钥（public-key cryptography），又称为公开密钥加密，服务端会生成一对密钥，一个私钥保存在服务端，仅本身知道，
另外一个是公钥，公钥能够自由发布供任何人使用。客户端的明文经过公钥加密后的密文须要用私钥解密。非对称密钥在加密和解密的过程的使用的密钥是不一样的密钥，
加密和解密是不对称的，因此称之为非对称加密。与对称密钥加密相比，非对称加密无需在客户端和服务端之间共享密钥，只要私钥不发给任何用户，
即便公钥在网上被截获，也没法被解密，仅有被窃取的公钥是没有任何用处的。常见的非对称加密有RSA，非对称加解密的过程：

1.服务端生成配对的公钥和私钥
2.私钥保存在服务端，公钥发送给客户端
3.客户端使用公钥加密明文传输给服务端
4.服务端使用私钥解密密文获得明文

数字签名

数据在浏览器和服务器之间传输时，有可能在传输过程当中被冒充的盗贼把内容替换了，那么如何保证数据是真实服务器发送的而不被调包呢，同时如何保证传输的数据没有被人篡改呢，
要解决这两个问题就必须用到数字签名，数字签名就如同平常生活的中的签名同样，一旦在合同书上落下了你的大名，从法律意义上就肯定是你本人签的字儿，这是任何人都无法仿造的，
由于这是你专有的手迹，任何人是造不出来的。那么在计算机中的数字签名怎么回事呢？数字签名就是用于验证传输的内容是否是真实服务器发送的数据，发送的数据有没有被篡改过，
它就干这两件事，是非对称加密的一种应用场景。不过他是反过来用私钥来加密，经过与之配对的公钥来解密。

第一步：服务端把报文通过Hash处理后生成摘要信息Digest，摘要信息使用私钥private-key加密以后就生成签名，服务器把签名连同报文一块儿发送给客户端。 
第二步：客户端接收到数据后，把签名提取出来用public-key解密，若是能正常的解密出来Digest2，那么就能确认是对方发的。 
第三步：客户端把报文Text提取出来作一样的Hash处理，获得的摘要信息Digest1，再与以前解密出来的Digist2对比，若是二者相等，就表示内容没有被篡改，
不然内容就是被人改过了。由于只要文本内容哪怕有任何一点点改动都会Hash出一个彻底不同的摘要信息出来。

数字证书（Certificate Authority）

数字证书简称CA，它由权威机构给某网站颁发的一种承认凭证，这个凭证是被你们（浏览器）所承认的，为何须要用数字证书呢，难道有了数字签名还不够安全吗？有这样一种状况，就是浏览器没法肯定全部的真实服务器是否是真的是真实的，举一个简单的例子：A厂家给大家家安装锁，同时把钥匙也交给你，只要钥匙能打开锁，你就能够肯定钥匙和锁是配对的，若是有人把钥匙换了或者把锁换了，你是打不开门的，你就知道确定被窃取了，可是若是有人把锁和钥匙替换成另外一套表面看起来差很少的，但质量差不少的，虽然钥匙和锁配套，可是你却不能肯定这是否真的是A厂家给你的，那么这时候，你能够找质检部门来检验一下，这套锁是否是真的来自于A厂家，质检部门是权威机构，他说的话是能够被公众承认的（呵呵）。

一样的， 由于若是有人（张三）用本身的公钥把真实服务器发送给浏览器的公钥替换了，因而张三用本身的私钥执行相同的步骤对文本Hash、数字签名，最后获得的结果都没什么问题，但事实上浏览器看到的东西却不是真实服务器给的，而是被张三从里到外（公钥到私钥）换了一通。那么如何保证你如今使用的公钥就是真实服务器发给你的呢？咱们就用数字证书来解决这个问题。数字证书通常由数字证书认证机构（Certificate Authority）颁发，证书里面包含了真实服务器的公钥和网站的一些其余信息，数字证书机构用本身的私钥加密后发给浏览器，浏览器使用数字证书机构的公钥解密后获得真实服务器的公钥。这个过程是创建在被你们所承认的证书机构之上获得的公钥，因此这是一种安全的方式。
相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程