OSI七层协议与TCP/IP五层协议体系
OSI:
- 应用层
- 表示层
- 会话层
- 传输层
- 网络层
- 数据链路层
- 物理层
TCP/IP
- 应用层 : FTP、DNS、Telnet、SMTP、HTTP、WWW、 POP3
- 传输层 : TCP、UDP
- 网络层 : IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP
- 数据链路层
- 物理层
HTTP与HTTPS
HTTP
浏览器输入网址后的执行过程:
- 客户端根据域名通过DNS解析得到对应的IP地址。
- 已知IP地址后,向服务器发起HTTP会话。
- 传输层使用TCP建立建立连接。
- 网络层通过路由将包发送到服务器。
- 链路层通过ARP协议获取目的主机的MAC地址,将包发送到服务器。
- 服务器响应请求,处理请求,并且返回网页数据(html等)。
- 浏览器根据返回的内容解析出网页。
HTTP状态码:
- 1xx:临时响应
- 2xx:成功
- 3xx:重定向(需要进一步操作)
- 4xx:请求错误,客户端错误
- 5xx:服务器错误
HTTP请求方法:
GET,POST
———以及———
- HEAD:类似于GET请求,不过返回的响应中没有具体内容,用于获取报头(起始行和首部,没有主体)
- PUT:传说中请求文档的一个版本
- DELETE:发出一个删除指定文档的请求
- TRACE:发送一个请求副本,以跟踪其处理进程
- OPTIONS:返回所有可用的方法,检查服务器支持哪些方法
- CONNECT:用于ssl隧道的基于代理的请求
GET:
语义:向服务器请求资源。
特点:通过URL传参,每次请求幂等,不改变服务器状态,多用于分享某个资源,安全性差。
POST:
语义:向服务器提交数据并请求处理(修改服务器资源)。
特点:将数据放在HTTP包中,每次请求不幂等,改变服务器状态(对服务器来说不安全),多用于私密信息的发送,安全性好。
HTTP报文
报文均是分为三个部分:起始行,首部和主体。
起始行:请求报文说明要做什么,响应报文朔评出现什么状态(状态码)。
首部:起始行之后跟随一行或者多行的首部字段,其格式是key:value 为的是便于解析,最后结束的时候多增加一个空行。
主体:主体则是非格式化,可以包含各种类型的数据,请求报文主体就是要发给服务器的数据,响应报文就是返回给浏览器的数据。
详细举例:
起始行(start line):
- 请求行:请求报文的起始行,包含一个方法和一个请求URL,还包含HTTP版本,所有这些用空格分隔。
- 响应行:响应报文的起始行,包含HTTP版本和数字状态码,由空格分隔。
首部(header):
部分举例
描述 | 首部实例 |
---|---|
服务器产生响应的日期 | Date:Tue,3Oct 1997 02:16:03 GMT |
实体的主体部分包含了15 040 字节的数据 | Content-length:15040 |
实体的主体部分是一个GIF 图片 | Content-type:image/gif |
客户端可以接收GIF 图片和JPEG 图片以及HTML | Accept: image/gif, image/jpeg, text/html |
具体说明:
- 日期,很想然是一个通用首部,表示穿件报文的日期。
- Accept首部,是请求报文独有的,表示客户端希望返回什么样的数据类型
首 部 | 描 述 |
---|---|
Accept | 告诉服务器能够发送哪些媒体类型 |
Accept-Charset | 告诉服务器能够发送哪些字符集 |
Accept-Encoding | 告诉服务器能够发送哪些编码方式 |
Accept-Language | 告诉服务器能够发送哪些语言 |
TE11 | 告诉服务器可以使用哪些扩展传输编码 |
- 安全请求首部,也是请求报文中的
首 部 | 描 述 |
---|---|
Authorization | 包含了客户端提供给服务器,以便对其自身进行认证的数据 |
Cookie | 客户端用它向服务器传送一个令牌——它并不是真正的安全首部,但确实隐含了安全功能14 |
Cookie2 | 用来说明请求端支持的cookie 版本,参见11.6.7 节 |
- 还有一些其他的请求首部,比如:User-Agent:产生请求的浏览器类型。Host:请求的主机名,允许多个域名同处一个IP地址,即虚拟主机。等
- 内容首部,说明主题部分的信息,通常响应报文中主要就是内容首部
首 部 | 描 述 |
---|---|
Content-Encoding | 对主体执行的任意编码方式 |
Content-Length | 主体的长度或尺寸 |
Content-Type | 这个主体的对象类型 |
其中一个首部是Connection: Keep-Alive,在http1.0中需要这个首部字段(请求和响应均有),而HTTP1.1则默认是keepalive,其作用是使用同一个TCP连接处理多个HTTP请求/应答。
HTTPS
HTTPS(全称:Hypertext Transfer Protocol over Secure Socket Layer)SSL上的HTTP
相对于HTTP的安全版,因为HTTP是不加密的,抓包信息均是明文可见的。
区别:一个快一个慢,一个不安全一个安全。
两者使用的端口也不一样HTTP使用80,HTTPS使用443。
加密过程:
首先通常使用非对称加密传输一个对称加密的公钥,之后就用这个公钥进行传输。
但是会出现中间人问题,就是讲二者互发的公钥换成自己的公钥,就可以解密信息了。
多说几句,就是无论对称加密还是非对称加密,总要有一样请求一个人人可见的公钥吧,这时候中间人只要将这个公钥换成自己的,尽管他不知道第一个公钥的私钥,但是他知道自己公钥的私钥,就可以将自己的替换后的公钥发送给了另一方,那么另一方发送的信息对于中间人就完全透明了。
为了证明我收到的(非对称加密)公钥就是你(服务器)发送的。我需要有一个验证机构,就是证书,证书里面记录了个人信息和他的公钥(google以及google的公钥)这样我向google请求公钥的时候和证书一比较,就知道是不是真的公钥了。
新的问题又来了,我收到的证书是不是真的呢?证书是假的, 那么公钥就是假的,那么信息就不安全。
方法就是我收到的不仅是证书,还有证书的用hash算法生成的摘要,类似于佐证的一个东东,一旦证书内容变化,摘要内容就会巨变。就是说仅仅改变证书上的公钥,我一对照摘要就知道二者不一致,是假的。但是,万一人家吧公钥和信息摘要一起改了咋办。。。
新的方法,找一个大家公认的安全机构CA(Certificate Authority)然后证书由CA发给某宝包括:
签发者、证书用途、某宝的公钥、某宝的加密算法、某宝用的HASH算法 等。
安全性体现在哪,就是证书的下面附一个签名,是将以上内容进行hash然后再将hash后的内容用CA的私钥进行加密,形成了签名。和证书一起发给某宝。
这样我们再请求数字证书的时候,为了证明我获得的公钥是证书提供的且证书上面的公钥是真的,就是对方的。首先要从CA处获取公钥(这个总不能是假的了吧,都是保存在浏览器上的),然后用公钥解密数字证书上用私钥加密过的数字签名,之后再用hash证书信息的值和解密后的值进行比较,ok一模一样。就可以使用证书的公钥进行加密了。之后就是自己随机生成一个对称加密的公钥,用证书上的公钥进行加密,之后对方收到之后就用自己的私钥解密,进而用随机生成的对称加密的公钥进行通信。
回到正题,https加密过程如下
客户端向服务端发送请求
服务端返回数字证书
- 客户端用自己的CA[主流的CA机构证书一般都内置在各个主流浏览器中]公钥去解密证书,如果证书有问题会提示风险
- 如果证书没问题客户端会生成一个对称加密的随机秘钥然后再和刚刚解密的服务器端的公钥对数据进行加密,然后发送给服务器端
- 服务器端收到以后会用自己的私钥对客户端发来的对称秘钥进行解密
- 之后双方就拿着这个对称加密秘钥来进行正常的通信
引用来自链接https://klionsec.github.io/2017/07/31/https-learn/非常感谢原作者
TCP与UDP、三次握手、四次挥手
TCP是面向连接,可靠的数据传输,保证了端到端的传输。
UDP则是非面向连接,不可靠,尽力而为的传输。
如上图所示(侵删)
三次握手:
建立连接的三次握手中第一次和第二次目的是为了同步两边的seq序号。
为什么有第三次而不是两次握手:
如果仅仅两次握手,那么对于任何一个客户端建立连接请求,服务器端都要为其建立连接。那么一旦某些无效的请求在网络中延时到达服务器端,建立了无效连接却不会得到客户端进一步请求,这样会浪费服务器端的资源。因此要继续通过第三次握手再确认一次。
四次挥手:
如图,当一方表示自己不再发送数据包时,比如客户端表示自己不需要发送请求了。就可以申请断开连接。但是另一端比如服务器端,在收到断开同时时,不会立刻断开,因此要等待自己待发送的数据全部发送完,才能断开连接。因此就要发送两个包,第一个表示对请求断开消息的确认,第二个则是表示自己也发送完数据包了,可以断开连接了。最后客户端则是对服务器端发送的第二个包的确认。
TCP的状态:
IP地址以及子网
A类地址:以0开头, 第一个字节范围:0~126(1.0.0.0 - 126.255.255.255)0和127段不使用;
B类地址:以10开头, 第一个字节范围:128~191(128.0.0.0 - 191.255.255.255);
C类地址:以110开头, 第一个字节范围:192~223(192.0.0.0 - 223.255.255.255);
10.0.0.0—10.255.255.255, 172.16.0.0—172.31.255.255, 192.168.0.0— 192.168.255.255。(Internet上保留地址用于内部)
IP地址与子网掩码相与得到网络号
199.42.26.0/28表示子网掩码为28位
网络号一致就表示式同一个子网,后面的主机号全0和全1不能使用。
ARP与RARP
ARP是通过IP地址查询MAC地址,维护一个IP-MAC缓存表。
RARP是通过MAC地址查询IP地址(很少被使用了)