计算机网络基础

2019-03-06  本文已影响0人  Man不经心

这是组内分享小明同学的分享课题，觉得不错，就拿过来放在资金的简书里面吧.

计算机网络

网络架构-网络分层

- 两种分层结构(自顶向下)

五层因特网协议栈 七层OSI参考模型
应用层 应用层
传输层 表示层
网络层 会话层
链路层 传输层
物理层 网络层
--- 链路层
--- 物理层 
1. 五层因特网协议栈分层利用的是网络协议来进行的分层。协议分层具有概念化和结构化的优点。
2. 七层OSI(著名的OSI/RM模型:Open System Interconnection/Reference Model)参考模型是国际标准化组织ISO(International Organization for
Standardization)在1978年提出了“开放系统互联参考模型”。

- 协议分层

1. 应用层

应用层是网络应用程序及它们的应用层协议存留的地方。

应用层协议包括HTTP(超文本传输协议：Web文档的请求和传送协议)、SMTP、POP3、IMAP(电子邮件报文的传送协议)、FTP(文件传送协议)、SIP(因特网电话协议)、DNS(域名系统协议)等。

image 
简单介绍一些应用层的知识点：
1、为了规定如何在各种端系统上组织应用程序，应用程序开发者设计了两种主流的应用程序体系结构(application architecture),分别是：客户-服务器体系结构
(client-server architecture)和对等体系结构(P2P：Peer To Peer)。
1.1、CS体系结构有两大特征：一、有一个总是打开的主机，称为服务器，它为许多其他称为客户的主机的请求提供服务。二、服务器具有固定的、周知的IP地址。
1.2、P2P体系机构对位于数据中心的专用服务器有最小的或者没有的依赖，应用程序可以在间断连接的主机对之间使用直接通信。特点：极大对自扩展性，
     例如：分享文件应用，每个主机都可以是一个服务器。
2、应用程序之间的通信实际上是进程(process)间的通信。一个进程可以被认为是运行在端系统中的一个程序。
2.1、进程通过套接字（socket）向网络发送报文和接收报文。

2. 传输层

3. 网络层

4. 链路层

5. 物理层

- OSI模型其余分层

1.会话层

2.表示层

具体协议的介绍

1、IP协议（Internet Protocol），网络之间互连的协议

A类:1.0.0.0~126.255.255.255,默认子网掩码/8,即255.0.0.0 (其中127.0.0.0~127.255.255.255为环回地址,用于本地环回测试等用途，
    其中0.0.0.0到0.255.255.255也是保留地址，用做表示所有的IP地址。)；

B类:128.0.0.0~191.255.255.255,默认子网掩码/16,即255.255.0.0；

C类:192.0.0.0~223.255.255.255,默认子网掩码/24,即255.255.255.0；

D类:224.0.0.0~239.255.255.255,一般于用组播，多点播送信息；

E类:240.0.0.0~255.255.255.255(其中255.255.255.255为全网广播地址),E类地址一般用于研究用途

- 用来指明一个IP地址所标示的主机处于哪个子网中。
例子：192.168.10.2➡172.16.10.2发送数据。
    IP地址为：192.168.10.2，子网掩码是255.255.255.0，IP地址为：172.16.10.2，子网掩码是255.255.0.0。
    按位与运算后分别是：192.168.10.0、172.16.0.0。
    不同表示不在同一个网段内。数据需要往外网发送。
    路由器转发数据报的时候用172.16.10.2和子网掩码做位与运算，得到172.16.0.0。
    然后在表中进行查询，如果与本地IP相同，则已经到达目的端，由当前路由解析数据；
    如果表中查询到有下一跳的路由IP，继续进行路由转发；
    在当前路由器中查询不到下一跳地址，即转向默认的下一跳IP(缺省路由)。

2、ARP协议（Address Resolution Protocal) ，地址解析协议

3、RARP协议（Reverse Address Resolution Protocol），反向地址转换协议

4、ICMP（Internet Control Message Protocol），Internet控制报文协议

1、侦测远端主机是否存在。
2、建立及维护路由资料。
3、重导资料传送路径（ICMP重定向）。
4、资料流量控制。

1、ping (目的IP/DNS域名)
2、tracert(win)/traceroute(mac) (目的IP) 可以显示中间经过的路由器
control+Z结束发送ICMP报文。

5、UDP协议（User Data Protocol，用户数据报协议）

1.无连接，即发送数据之前不需要建立连接。无连接的好处就是快，省内存空间。因为维护连接需要创建大量的数据结构，在这里都不需要。
2.UDP尽最大努力交付数据，即不保证可靠交付。没有TCP的确认机制、重传机制。如果因为网络原因没有传送到对端，UDP也不会给应用层返回错误信息。
3.面向数据报文。对于应用层交付下来的报文在添加了首部就直接交付于ip层，不会进行合并，也不会进行拆分。这就说明UDP一次交付一个完整的报文。
  正是因为这样，UDP显得不够灵活，不能控制读写数据的次数和数量。
  比如我们要发送100个字节的报文，我们调用一次sendto函数就会发送100字节，
  对端也需要用recvfrom函数一次性接收100字节，不能使用循环每次获取10个字节，获取十次这样的做法。
4.没有拥塞控制，所以当网络出现的拥塞不会导致主机发送数据的速率降低。这个在对实时应用来说很重要，比如：视频通话、直播等应用。
5.UDP支持一对一、一对多、多对一、多对多的交互通信。
6.UDP的首部只有8个字节，开销小。

[图片上传失败...(image-1473e5-1551839300985)]

1.UDP报文段头部总共8字节。
2.检验和提供了差错检测功能。即用于确定当UDP报文段从源到达目的地移动时，其中的比特是否发生了变化。

计算方法：
1.按每16位求和，校验和初始值为0；
2.如果求和时遇到了任何的溢出，则需要做"回卷"（溢出位加到新值末尾）；
3.加完所有报文段中的数据，最后使用"反码"运算得出校验和，组装发送给接收方。
4.接收方接收到报文段后，重复1、2步骤。最后 再和校验和值求和。
5.结果：如果报文段没有引入差错，最后求和结果应该为1111111111111111。
       如果引入了差错，最后16位求和结果肯定包含0。
image 
NFS：网络文件系统
TFTP：简单文件传输协议
DNS：域名解析协议
DHCP：动态主机配置协议
SNMP：简单网络管理协议

6、DNS域名解析协议

DNS协议也可以叫做因特网的目录服务协议。因为它就是为了便于大家记忆主机地址而设计出来的，它的作用就是将便于人记忆的主机名解析为便于电子设备解析的IP地址。

比较直观的例子就是：百度

域名地址 IP地址
www.baidu.com http://119.75.217.109
··· http://115.239.211.112

DNS协议层级从上到下划分

  1. 根DNS服务器
  2. 顶级域DNS服务器
  3. 权威DNS服务器
  4. 本地DNS服务器
  5. 操作系统本地DNS缓存
  6. 浏览器本地DNS缓存

模拟一个http请求过程中的域名解析过程

  1. 浏览器开始请求，先检查浏览器本地DNS缓存中是否存在域名对应的IP地址，如果有，解析结束，更新缓存时间。如果没有，继续走。
  2. 浏览器接着检查操作系统中的本地DNS缓存中是否存在域名对应的IP地址，如果有，解析结束，更新缓存时间。如果没有，继续走。
  3. 开始请求本地DNS服务器来解析域名，如果命中，解析结束，更新缓存时间。如果没有，继续走。（这台服务器相当于一台代理解析服务器，距离主机相对较近，并且具有较好的性能，大约80%的域名解析都在这一层级的服务器中完成）
  4. 本地DNS服务器将请求域名发送给根DNS服务器解析。
  5. 根DNS服务器返回给本地DNS服务器一个请求域名所在的顶级域DNS服务器地址。
  6. 本地DNS服务器拿到顶级域DNS服务器的地址，并向它发送请求域名进行解析。
  7. 顶级域DNS服务器返回给本地DNS服务器一个请求域名所在的权威DNS服务器地址。（权威DNS服务器即请求域名注册时所使用的服务器）
  8. 权威DNS服务器根据域名-IP映射关系表查询到对应IP地址，返回给本地DNS服务器。
  9. 本地DNS服务器收到IP地址，返回给浏览器，并向向表中缓存一条新的映射关系。
  10. 浏览器收到解析结果IP，缓存到本地。域名解析过程结束，继续HTTP请求。
image

7、TCP协议（Transmission Control Protocol 传输控制协议）

image 
1、16位源端口号：16位的源端口中包含初始化通信的端口。源端口的作用是标识报文的返回地址。
2、16位目的端口号：16位的目的端口域定义传输的目的。
3、32位序号：表明了发送的数据报的顺序。
4、32位确认序号：希望收到的下一个数据报的序号。
5、4位首部长度：记录着TCP首部长度，指明何处数据开始。
6、保留（6位）：6位值域，这些位必须是0。为了将来定义新的用途而保留。
7、标志：6位标志域。表示为：紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是：URG、ACK、PSH、RST、SYN、FIN。
   这6位详细信息在下面介绍。
8、16位窗口大小：用来表示想收到的每个TCP数据报的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。
9、16位校验和：发送端基于数据内容计算校验头部、数据和伪TCP头部之和，接收端要与发送端数值结果完全一样，从而证明数据的有效性。
10、16位紧急指针：在标志URG=1时才有效。加快处理标示为紧急的数据段。
11、选项：可选设置项。长度不定，最长40个字节。（时间戳计算往返时间）
12、数据：该TCP数据报负载的数据。

URG：紧急标志。紧急标志为"1"表明该位有效。
ACK：确认标志。为1表明32位确认序号有效。为0表明数据报不包含确认序号信息。
PSH：推标志。该标志为1时，接收端不将该数据进行队列处理，而是尽可能快地将数据转由应用处理。
RST：复位标志。用于复位相应的TCP连接。
SYN：同步标志。表明建立连接
FIN：四次挥手结束标志。表明四次挥手断开TCP连接。

[图片上传失败...(image-93899f-1551839300985)]

所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

1、第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。
2、第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，
   并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。
3、第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，
   并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，
   随后Client与Server之间可以开始传输数据了。

[图片上传失败...(image-2ad7c1-1551839300985)]

四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开

1、第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
2、第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
3、第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
4、第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。

为什么TCP握手是三次???

答：TCP是可靠的传输控制协议，三次握手能保证数据可靠传输又能提高传输效率。

如果TCP的握手是两次： 即server端发送ACK确认报文就成功建立连接
并且假设TCP发送ACK确认的报文丢失，但是此时server端已经是Established状态。
client端因为没有收到ACK确认报文，开始重新发送SYN请求建立连接报文，
但是server端此时却已经是Established状态，认为已经建立好了连接。逻辑冲突。

如果TCP的握手是三次就可以避免上面这种情况：
因为即使TCP发送ACK确认的报文丢失，但是server端也还是SYN_receive状态，
client端因为没有收到ACK确认报文，开始重新发送SYN请求建立连接报文，
server端收到SYN请求建立连接报文，会重新发送一个ACK确认报文。

如果TCP的握手是四次： 
1.client给server发送SYN同步报文； 
2.server收到SYN后，给client回复ACK确认报文； 
3.server给client发送SYN同步报文； 
4.client给server发送ACK确认报文。 
第2.3步之间，server和client没有任何的数据交互，分开发送相当于多发了一次TCP报文段，
SYN和ACK标识只是TCP报头的一个标识位。很明显，这两步可以合并，从而提高连接的速度和效率。

为什么TCP挥手是四次???

答：原因是client和server两端都需要一个FIN和ACK报文，
但是假设client端发送了一个FIN报文后，server端回复一个ACK确认报文，
这仅仅表示client端不会再发送数据了，却还能接收数据，
server端也未必把数据发送给了client端。
所以要真正关闭连接需要server端发送完剩余数据后，再发送给client端一个FIN报文。
得到client端的ACK报文后，才说明TCP已经断开连接。

假设：如果挥手的第2、3步合起来，和握手的第2步类似，有可行性吗？
答：不可能。如果server端还有大量数据需要几个MSL的时间才能发送完，回复给client端的ACK确认报文就会延时几个MSL的时间，
导致client重试而发送多个FIN报文，直到得到ACK确认报文。

为什么建立连接需要三次握手，而断开连接需要四次握手???

答：这是因为server端在Listen状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，当收到client端的FIN报文时，仅仅表示client端不再发送数据了但是还能接收数据，server端也未必全部数据都发送给client端了，
所以server端可以立即close，也可以发送一些数据给client端后，再发送FIN报文给client端来表示同意现在关闭连接，
因此，server端ACK和FIN一般都会分开发送。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？？？

1、保证TCP协议的全双工连接能够可靠关闭
2、保证这次连接的重复数据段从网络中消失

第一点，如果client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致server没有收到client最后回复的ACK。
那么server就会在超时之后继续发送FIN，此时由于client已经CLOSED了，就找不到与重发的FIN对应的连接，
最后server就会收到RST而不是ACK，server就会以为是连接错误把问题报告给高层。
这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。
所以，client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。
也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：
假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，
由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，
于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。
所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。
" MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长的最长时间，超过这个时间报文将被丢弃。"

8.HTTP协议(Hyper Text Transfer Protocol(超文本传输协议))

https://lrh1993.gitbooks.io/android_interview_guide/content/computer-networks/http.html

服务器向客户发送被请求的文件，但是不会存储任何关于客户的状态信息。
假如一个客户在短时间内多次请求了同一个链接地址，服务器并不会因为刚刚为客户提供了响应就不再作出反应，
而是会多次重新发送同一个超文本内容给客户，就像是服务器已经完全忘记了不久之前所做过的事。
因为HTTP协议不会保存客户的信息，所以说HTTP是一个"无状态协议"。
image 
//请求行
GET /Service/IndexSvr.svc/GetIndexPage?modilarId=115554&pageNo=1&styleId=460&appId=136&appKey=d0779&projectId=1 HTTP/1.1
//请求头部/首部行 start
random: 999
token: a54e970b848cd3624ce2cba0408d4bb413ece1f5c57194a14ba17b6afe61fcbd2b8182ebf929d0c22db7a3962cad62ed7549e346566be05f15d7064ffa5cd5bd1541742453270
Host: testparty.api.xinhuaapp.com
Accept-Encoding: gzip
User-Agent: okhttp/3.10.0
Connection: keep-alive
//请求头部/首部行 end
//空行<CR><LF>
--------------------------分割线-------------------------------
//请求行
POST /Service/UserSvr.svc/GetPushList HTTP/1.1
//请求头部/首部行 start
random: 999
token: c1686787683cce8334f3396f3a2198df0194e4a8786c4ebb902379ae7cac5d10b5dd2457bf890ba79e21c7cc376b528c6985065e31857bfeb758c287df9cfa6a1542013083957
Content-Type: application/json; charset=UTF-8
Content-Length: 89
Host: testcloudapi.xinhuaapp.com
Accept-Encoding: gzip
User-Agent: okhttp/3.11.0
Connection: keep-alive
//请求头部/首部行 end
//空行<CR><LF>
//实体体
{"messageType":0,"pageNo":1,"adminId":9633,"appId":110083,"appKey":"xy001","projectId":4}

HTTP/1.0定义了3种请求方法：GET, POST, HEAD。
HTTP/1.1新增了5种请求方法：OPTIONS, PUT, DELETE, TRACE, CONNECT。

GET      请求指定的资源。
HEAD     类似于get请求，用于获取报头，没有资源内容。
POST     传输实体对象数据，向指定资源请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT      用于传输文件。
DELETE   请求服务器删除指定的资源。
CONNECT  HTTP/1.1协议中的请求方法。客户端与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。
         主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。
OPTIONS  允许客户端查看服务器的性能。例如：查询后台支持的请求方法。
TRACE    回显服务器收到的请求，主要用于测试或诊断。
image 
//状态行
HTTP/1.1 200 OK
/* 首部行 start */
Server: openresty
Date: Mon, 19 Nov 2018 12:56:48 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 79788
Cache-Control: private
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Connection: keep-alive
/* 首部行 end */
//空行
//实体体
{"Data":{"AdvertBoxData":{"PopupBox":null,"SuspendBox":null},"Focus":[{"DisplayMode":"DNWS002","Template":"TNWS004","ActionColor":"","AuditPolicy":0,"BackGroundUrl":"","CanComment":0,"CompanyIcon":"","CompanyName":"","ContentType":0,"Fixed":0,"Id":98,"ImgUrl":"http:\/\/xinhuaapp-img.img.aliyuncs.com\/Party\/1\/136\/modilar\/2018\/03\/21\/2018032116054916584459.jpg?x-oss-process=image\/crop,x_0,y_0,w_978,h_679\/quality,q_80\/format,jpg","ImgUrlAction":"","IsDefault":0,"IsInLink":0,"IsIndex":0,"IsShare":0,"IssueTime":"\/Date(1533623226840+0800)\/","IssueTimeText":"2018-08-07","LastContentImg":"","LastContentTitle":"","LinkUrl":"http:\/\/www.baidu.com","Meno":"","ModilarSub":[],"ModliarTitle":"","ShareUrl":"http:\/\/www.baidu.com","Sorts":0,"SoundUrl":"","Source":"","SubModilars":0,"Tags":null,"TagsColor":null,"Title":"【推广】打一行整的咔","UpdateTimeStamp":0,"VodUrl":""}]}}
---------------------------分割线-------------------------
HTTP/1.1 200 OK
Server: openresty
Date: Mon, 19 Nov 2018 12:58:27 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 783
Cache-Control: private
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Connection: keep-alive

{"Data":[{"ContentTitle":"","CreateUser":9653,"DeadLine":"2018-11-19Monday20:58","MessageType":16,"ObjId":676,"PushContent":"[wwww]已通过您的选题","PushId":19966,"PushTime":"2018-11-14 17:21","ReleaseName":"","Template":"","Title":"选题消息"},{"ContentTitle":"","CreateUser":9633,"DeadLine":"2018-11-19Monday20:58","MessageType":8,"ObjId":1811395,"PushContent":"[陈明军]已退回您的稿件","PushId":9926,"PushTime":"2018-10-24 15:02","ReleaseName":"","Template":"","Title":"稿件消息"},{"ContentTitle":"","CreateUser":9624,"DeadLine":"2018-11-19Monday20:58","MessageType":4,"ObjId":611,"PushContent":"[测试]已完成任务","PushId":19999,"PushTime":"2018-11-19 16:15","ReleaseName":"","Template":"","Title":"任务消息"}],"Message":"操作成功","Status":1}

1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求，比如说存取缓存操作
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误

1. 内容编码

Accept-Encoding:gzip,compress,deflate,identity 代表请求方通知接收方，可以用的内容压缩编码格式。

Content-Encoding:gzip/compress/deflate/identity 代表报文内容压缩的编码格式，接收方通过指定的编码格式进行解压。

2. 传输编码

Transfer-Encoding:chunked(分块传输)/gzip/compress/deflate/identity

规定了传输报文主体时采用的编码方式。

当传输大量数据而无法获得报文主体长度(Content-Length)时，分块传输方式就起到了非常重要的作用，因为它可以逐块表明长度。

chunked
数据以一系列分块的形式进行发送。 Content-Length 首部在这种情况下不被发送。。
在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着 '\r\n' ，之后是分块本身，后面也是'\r\n' 。
终止块是一个常规的分块，不同之处在于其长度为0。终止块后面是一个挂载（trailer），由一系列（或者为空）的实体消息首部构成。

3. Connection

Connection:keep-alive/close 代表HTTP使用持久连接/关闭连接。

Connection:控制代理不再转发的首部字段


image

4. Trailer

事先说明在报文内容主体后记录了哪些字段首部字段

示例：

headers...
Transfer-Encoding: chunked
Trailer:Expires
body...
0//分块长度
Expires:Tue,23 Sep 2019 23:23:22 GMT
body...
7
Expires:Tue,23 Sep 2019 23:23:22 GMT
body...
9
Expires:Tue,23 Sep 2019 23:23:22 GMT
}

- cookie技术

image 
1.背景
  因为HTTP是无状态的连接，所以服务器并未保存客户端的信息。
  但是一些Web服务器因为功能需求的原因，恰恰需要能够识别用户。
  例如最典型的记录用户访问次数、购物网站中的购物车功能。
  所以HTTP使用了cookie。
2.cookie的4个组成部分
  Ⅰ.在HTTP响应报文中的cookie首部行：Set-Cookie:myCookie=123;domain=www.baidu.com;path=/one/;expires=Mon,22-Jan-07 07:10:24 GMT;Secure;HttpOnly
  Ⅱ.在HTTP请求报文中的cookie首部行：Cookie: $Version=1; Skin=new;
  Ⅲ.在客户端系统浏览器中保存了一个cookie文件。
  Ⅳ.在Web服务器的一个数据库表中。
3.cookie的属性
  String name：该Cookie的名称。Cookie一旦创建，名称便不可更改。 
  int maxAge：该Cookie失效的时间，单位秒。如果为正数，则该Cookie在>maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为–1。 
  Boolean secure：该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，在网络上传输数据之前先将数据加密。默认为false。 
  String path：该Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。
  String domain：可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”。 
  String comment：该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明。 
  int version：该Cookie使用的版本号。0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范。
  Object value：该Cookie的值。如果值为Unicode字符，需要使用字符编码。如果值为二进制数据，则需要使用BASE64编码。 
4.cookie的争议
  Ⅰ.被讨论最多的就是隐私问题
  Ⅱ.Cookie引入的各种安全问题
  Ⅲ.与REST软件架构相背离。Web 应用程序最重要的 RESTful 原则是，客户端和服务器之间的交互在请求之间是无状态的。
  Ⅳ.过多使用浪费HTTP请求流量。

An <a href="http://tools.ietf.org/html/rfc6265">RFC 6265</a> Cookie.

image

HTTPS（HTTP Secure，超文本传输安全协议）

1、HTTP协议的主要不足

Ⅰ.通信使用明文（不加密），内容可能会被窃听
Ⅱ.不验证通信方的身份，因此有可能遭遇伪装
Ⅲ.无法证明报文的完整性，所以有可能已遭篡改

2、解决办法

1.加密处理防止被窃听
  Ⅰ.内容加密
    将参与通信的内容本身加密的方式。由于 HTTP 协议中没有加密机制，那么就对 HTTP 协议传输的内容本身加密。
    即把 HTTP 报文里所含的内容进行加密处理。
    有一点必须引起注意，由于该方式不同于 SSL 或 TLS 将整个通信线路加密处理，所以内容仍有被篡改的风险。
  Ⅱ.通信加密
    通过和SSL（Secure Socket Layer，安全套接层协议）或TLS（Transport LayerSecurity，安全层传输协议）的组合使用，加密 HTTP 的通信内容。
    用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP 通信了。
    与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTP Secure，超文本传输安全协议）或 HTTP over SSL。
2.检测数字证书防止遭遇伪装
  HTTP 协议（无状态协议）无法确定通信方，但使用 SSL 则可以。
  SSL 不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定通信方。
  证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。
  有名的三方证书机构：威瑞信（VeriSign）
  通过使用证书，以证明通信方就是对的服务器。这对客户端个人来讲，也减少了个人信息泄露的危险性。
3.利用SSL协议的数字摘要和数字签名功能保证数据完整性
  Ⅰ.数字摘要是采用单向Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，
    它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。
    “数字摘要”是https能确保数据完整性和防篡改的根本原因。
  Ⅱ.数字签名技术就是对“非对称密钥加解密”和“数字摘要”两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。
    接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用Hash函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。
    如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

3、了解SSL/TLS协议&版本

1. SSL（Secure Socket Layer，安全套接字层）
  SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密技术，可确保数据在网络上传输过程中不会被截取，当前为3.0版本。
  SSL协议可分为两层：
  SSL记录协议（SSL Recore Protocol）：它建立在可靠地传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
  SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份证、协商加密算法、交换加密密钥等。

2. TLS（Transport Layer Security，传输层安全协议）
  用于两个应用程序之间提供保密性和数据完整性。
  TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，
  是SSL 3.0的后续版本，可以理解为SSL 3.1。
  该协议由两层组成：TLS记录协议（TLS Recore）和TLS握手协议（TLS Handshake）。

3. SSL/TLS协议作用
  Ⅰ.认证用户和服务器，确保数据发送到正确的客户机和服务器；（意思是HTTP的可能会发送到不正确的客户机和服务器）
  Ⅱ.加密数据以防止数据中途被窃取。
  Ⅲ.维护数据的完整性，确保数据在传输过程中不被改变。

1.混合加密机制
  Ⅰ.对称加密
    对称加密（也叫私钥加密）指加密和解密使用相同密钥的加密算法。
    有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。
    而在大多数的对称算法中，加密秘钥和解密密钥是相同的，所以也称这种加密算法为秘密密钥算法或者单密钥算法。
    常见的对称加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA等。
    缺陷：容易被解密。
  Ⅱ.非对称加密
    与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。
    公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
    因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。
    常见的非对称加密算法有：RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）等。
    缺陷：加解密处理时间相对较长。
  Ⅲ.HTTPS采用混合加密
    充分利用以上两个加解密机制的优点。
    "在交换密钥阶段使用非对称加密"。
    "在交换报文阶段则使用对称加密"。
    总结起来就是使用非对称加密交换之后的密钥，拿来作为之后交换报文段的对称加密所使用的密钥。

[图片上传失败...(image-7470b1-1551839300985)]

公钥是如何获取的？如何安全地获取？
难道又是由非对称加密传输完成？这样只会陷入鸡生蛋蛋生鸡，永无止境的困局。
这里我们引入了数字证书的概念。

2.简单介绍证书验证原理
  Ⅰ.服务端首先把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。
  Ⅱ.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密服务端的公钥，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给服务端。
  Ⅲ.服务端把自己申请的证书返回给客户端。
  Ⅳ.客户端收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，"各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥"。
  所以客户端只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。
  客户端按照同样的签名规则，自己也生成一个证书签名，如果“两个签名一致”，说明证书是有效的。
  验证成功后，客户端就可以放心地再次利用机构公钥，解密出服务端的公钥Key1。
  Ⅴ.客户端生成自己的对称加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给服务端。
  Ⅵ.服务端用自己的私钥解开加密，得到对称加密密钥Key2。于是两人开始用Key2进行对称加密的通信。
image 
1.HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
2.HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
3.HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4.HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。
image 
1.缓存处理。
  在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，
  HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2.带宽优化及网络连接的使用。
  HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，
  HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3.错误通知的管理。
  在HTTP1.1中新增了24个错误状态响应码，如：
  409（Conflict）表示请求的资源与资源的当前状态发生冲突；
  410（Gone）表示服务器上的某个资源被永久性的删除。
4.Host头处理。
  在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。
  但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
  HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
5.长连接。
  HTTP1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，
  在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。
  在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

1、缓存规则

image 
HTTP缓存有很多种规则，根据是否需要重新向服务器发起请求来分类，可以将其分为两大类："强制缓存"，"对比缓存"。
通常使用两种缓存结合的方式进行缓存资源。优先级："强制缓存 > 对比缓存"

2、强制缓存缓存规则

image

3、对比缓存缓存规则

image

4、强制缓存原理

  1. 在没有缓存数据的时候，浏览器向服务器请求数据时，服务器会将==数据==和==缓存规则Expires/Cache-Control==一并返回，缓存规则信息包含在响应header中。
  2. HTTP1.0:Expires的值为服务端返回的到期时间，即下一次请求时，请求时间小于服务端返回的到期时间，直接使用缓存数据。
  3. HTTP1.1:Cache-Control
常见的取值：
private:      只对特定用户提供此缓存数据。
public:       客户端和代理服务器都可缓存，且所有用户都可以使用此缓存数据
max-age=xxx:  缓存的内容将在 xxx 秒后失效("强制缓存规则使用")
no-cache:     强制向源服务器再次验证,即需要使用"对比缓存"来验证缓存数据
no-store:     所有内容都不会缓存，强制缓存，对比缓存都不会触发。完全从服务器获取最新数据

5、对比缓存原理

  1. 对比缓存，顾名思义，==需要进行比较判断是否可以使用缓存==。
  2. 浏览器第一次请求数据时，服务器会将==缓存标识与数据==一起返回给客户端，客户端将二者备份至缓存数据库中。
  3. 再次请求数据时，客户端将备份的==缓存标识==发送给服务器，服务器根据缓存标识进行判断，判断成功后，返回304状态码，通知客户端==比较成功==，可以使用缓存数据。
  4. 缓存标识
4-1. 记录缓存：Last-Modified  请求数据：If-Modified-Since
Last-Modified：服务器返回资源的最后修改时间。客户端做保存。
If-Modified-Since：客户端重新请求时，将上面"保存的最后修改时间"使用If-Modified-Since传给服务器。
                   服务器拿到后，将它与本地资源的最后修改时间"做对比"。
                   若资源的最后修改时间"大于"If-Modified-Since，说明资源有被改动过，则"响应整片资源内容"，返回状态码"200"；
                   若资源的最后修改时间"小于或等于"If-Modified-Since，说明资源无新修改，则响应HTTP "304"，告知浏览器继续"使用所保存的cache"。

4-2. 记录缓存：Etag  请求数据：If-None-Match（优先级高于Last-Modified  /  If-Modified-Since）
Etag:服务器返回当前资源在服务器中的唯一标识（UUID）。客户端做保存。
If-None-Match：客户端重新请求时，将上面"保存的唯一标识"使用If-None-Match传给服务器。
               服务器拿到后，将它与本地资源的唯一标识"做对比"。
               "不同"，说明资源有被改动过，则"响应整片资源内容"，返回状态码"200"；
               "相同"，说明资源无新修改，则响应HTTP "304"，告知浏览器继续"使用所保存的cache"。

6.缓存机制总结

对于强制缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
对于比较缓存，将缓存信息中的Etag和Last-Modified通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存。
image 
1.请求延迟。（长连接复用（keep-alive）的缺点是：HOL blocking/Head-of-line blocking 排头阻塞（HTTP报文串行传输）（请求-响应-请求））
2.安全性问题。（在不使用HTTPS的前提下）

1.SPDY

SPDY（读作“SPeeDY”）是Google开发的基于TCP的应用层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。
SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。

2.SPDY增强功能

1.多路复用功能降低延迟。
  针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。
  多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率。
2.请求优先级（request prioritization）。
  多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。
  SPDY允许给每个request设置优先级，这样重要的请求就会优先得到响应。
  比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
3.header压缩。
  前面提到HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。
4.强制使用SSL协议。
  基于HTTPS的加密协议传输，大大提高了传输数据的可靠性。
5.服务端推送（server push）。
  采用了SPDY的网页，例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，
  当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了。

[图片上传失败...(image-5c917b-1551839300985)]

  1. HTTP/2（超文本传输协议第2版，最初命名为HTTP 2.0），是HTTP协议的的第二个主要版本，使用于万维网。HTTP/2是HTTP协议自1999年HTTP 1.1发布后的首个更新，主要基于SPDY协议。
Akamai 公司建立的一个官方的演示，同时请求 379 张图片。
image 
    1.HTTP2在它和传输层(TCP or UDP)之间增加了一个二进制分帧层。
    2.在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。
    3.对应的首部信息会被封装到 HEADER frame里，而相应的 Request Body 则封装到 DATA frame 里面。
image

Ⅱ. HTTP2.0的多路复用和HTTP1.1中的长连接复用区别

1.HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，
  一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞(head-of-line blocking)；
2.HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；
image 
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。

1.减少 TCP 三次握手及 TLS 握手时间。
2.改进的拥塞控制。
3.避免队头阻塞的多路复用。
4.连接迁移。
5.前向冗余纠错。

Ⅳ. 2015 年 QUIC 被提议作为 IETF 的标准草案，2016 年 7 月，IETF 正式提出了 HTTP-over-QUIC。2018 年 11 月 IETF HTTP 和 QUIC 工作组主席 Mark Nottingham 正式提出将 HTPP-over-QUIC 重命名为 HTTP/3.0。随后的几天讨论中，此项提议被 IETF 成员接受，并给出了官方认可。

上一篇 下一篇

猜你喜欢

热点阅读