阅读 237

笔记:网络基础TCP、HTTP、HTTPS(HTTP+SSL)

[TOC]

@(iOS总结)

一切从简,用自己的方式记录。如果你觉得啰嗦,那可能是我怕说的不明白;如果你觉得太笼统,那可能是我觉得太基础没写出来,或者我还没认知到;如果你觉得和别的文章太重复,那可能是我没有找到更好的表达方式;

系统学习最好看一下 UNIX网络编程卷1:套接字联网API(第3版).pdf

一、TCP(详情参考:必须懂的计算机网络知识—(TCP)

1.1、网络模型数据处理过程

1.2、TCP和UDP的区别

TCP位于传输层,传输层协议还包括UDPHTTP(超文本传输协议)、FTP(文件传输协议)、SNMP(简单网络管理协议)、Telnet(远程登录协议)等。下面的表格列出了TCPUDP的区别。

传输层协议 TCP(Transmission Control Protocol传输控制协议) UDP(User Datagram Protocol用户数据报协议)
连接方式 面向连接(一对一) 无连接(一对一、一对多、多对一、多对多)
占用系统资源 多(首部开销20字节) 少(首部开销8字节)
可靠性 可靠,保证数据正确(全双工) 不可靠,可能会丢包
数据顺序 保证数据顺序 不保证数据顺序
拥塞控制 有拥塞控制,面向数据流 无拥塞控制,面向报文
流量控制 有(滑动窗口)

注意:ping”命令是使用 IP 和网络控制信息协议 (ICMP),因而没有涉及到任何传输协议(UDP/TCP) 和应用程序


TCP因为是面向连接的,所以比UDP要更复杂,建立连接需要三次握手,断开连接需要四次挥手。TCP充分实现了数据传输时各种控制功能,可以进行丢包的重发控制,还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外,TCP作为一种面向有连接的协议,只有在确认通信对端存在时才会发送数据,从而可以控制通信流量的浪费。TCP通过检验和序列号确认应答重发控制连接管理以及窗口控制等机制实现可靠性传输

1.3、建立连接为什么要三次握手?

假如让我和你来实现一次完整可靠的连接,会怎么做呢?

  • 第一次握手告诉我要和你建立连接
  • 第二次握手告诉你能收到我发送的消息
  • 第三次握手告诉我能收到你发送的消息 然后,你能收到我发送的,我能收到你发送的,咱俩下面就可以畅聊了

1.4、断开连接为什么要四次挥手?

  • 第一次握手告诉我要和你断开连接
  • 第二次握手告诉你收到我发送的断开连接消息了,但是可能还有数据没有发送完毕,等一会再告诉我
  • 第三次握手告诉你没有正在发送的数据了,你可以和我断开连接了
  • 第四次挥手告诉我收到你发送的可以和我断开连接的消息了 然后,本次会话完美结束了,没有漏掉任何消息

1.5、TCP流量控制

所谓的流量控制就是接收方让发送方的发送速率不要太快,让接收方来得及接收。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP窗口的单位是字节,不是报文段,发送方的发送窗口不能大于接收方给出的接收窗口(rwnd)的大小。

1.6、TCP拥塞控制

为了方式网络的拥塞现象,TCP提出了一系列的拥塞控制机制。拥塞控制的原理主要依赖于一个拥塞窗口(cwnd),发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就增大一写,以便把更多的分组发送出去。但是只要出现网络拥塞,拥塞窗口就减少一些,以便减少注入到网络中的分组。主要有四种算法:慢启动(Slow-start)拥塞避免(Congestion Avoidance)快重传(Fast Restrangsmit)、快恢复(Fast Recovery)。

拥塞控制和流量控制的区别

区别 拥塞控制 流量控制
作用范围 全局性的(设计所有主机、路由器、以及与降低网络传输性能有关的所有因素) 点对点的通信量控制,是个端到端的问题
控制方 发送方控制 接收方控制
控制结果 控制发送方注入到网络中的数据量 控制发送端的发送数据速率,以便接收端来得及接收

二、HTTP、HTTPS

2.1、HTTP(详情参考:HTTP 教程| 菜鸟教程关于HTTP协议,一篇就够了

HTTP协议是Hyper Text Transfer Protocol(超文本传输协议)的缩写,是用于从万维网(WWW:World Wide Web )服务器传输超文本到本地浏览器的传送协议。规范把 HTTP 请求分为三个部分:状态行请求头消息主体

2.1.1、HTTP基础知识:URL

统一资源定位符(Uniform Resource Locator)是网络资源的位置和访问方法的简洁表示。常见的url包括4个部分,结构如下图:

组件 含义
方案 使用的协议,如http或https
主机 服务器的域名或IP地址
路径 服务器上资源的本地名,用(/)与前面的scheme分隔开来
查询字符串 通过查询字符串来减小请求资源类型的范围,如参数

2.1.2、HTTP之状态码

状态代码有三位数字组成,第一个数字定义了响应的类别,共分五种类别: 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        //服务器当前不能处理客户端的请求,一段时间后可能恢复正常
复制代码

2.1.3、HTTP请求方法

根据HTTP标准,HTTP请求可以使用多种请求方法。 HTTP1.0定义了三种请求方法: GET, POST 和 HEAD方法。 HTTP1.1新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

GET  请求指定的页面信息,并返回实体主体。
HEAD     类似于get请求,只不过返回的响应中没有具体的内容,用于获取报头
POST     向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT  从客户端向服务器传送的数据取代指定的文档的内容。
DELETE   请求服务器删除指定的页面。
CONNECT  HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS  允许客户端查看服务器的性能。
TRACE    回显服务器收到的请求,主要用于测试或诊断。
复制代码

2.1.4、HTTP与TCP的区别?

TCP协议对应于传输层,HTTP协议对应于应用层,从本质上来说二者没有可比性。 很多人喜欢把IP比作告诉公路,TCP是告诉公路上的卡车,他们携带的货物就是HTTP协议。 我觉得这是很不严谨的,如果非要举个形象的例子,我觉得可以把IP比作电话号码TCP就像电话,传输去的声音就像数据包,如果是开会就会遵循电话会议规则(比如HTTP),如果是销售就会遵循推销规则(比如FTP),如果是闲聊就按照双方想要的规则(自定义数据传输协议)。 TCP传输的数据包可以任何格式的,可以自定义规则,可以遵循HTTP协议,也可以遵循FTP协议。

2.1.5、如何解决HTTP的无状态协议?

使用Cookie来解决无状态的问题,Cookie就相当于一个通行证,第一次访问的时候给客户端发送一个Cookie,当客户端再次来的时候,拿着Cookie(通行证),那么服务器就知道这个是”老用户“。

2.2、HTTPS(详情参考:详细解析 HTTP 与 HTTPS 的区别

https, 全称Hyper Text Transfer Protocol Secure,相比http,多了一个secure。一句话:HTTPS=HTTP+加密+认证+完整性保护

理清几个概念很重要

  • 1、CA(数字证书颁发机构)
  • 2、非对称秘钥:CA的一对非对称秘钥、服务器的一对非对称秘钥、客户端的一对非对称秘钥
  • 3、对称秘钥:客户端随机生成的,用于认证完成之后的数据加解密(客户端通过服务器返回的数字证书中的公钥加密对称秘钥后,发送给服务器)
  • 4、数字证书:CA颁发给服务器的数字证书(证书中的公钥是服务器的公钥,但是签名使用的是CA的私钥)、CA根证书(证书中的公钥是CA自己的公钥,签名使用的是CA自己的私钥<用来保证该证书没有被中间篡改过>)
  • 5、单双向认证:单向认证,客户端验证服务器;双向认证,客户端先验证服务器证书,服务器在验证客户端的证书。双向认证的时候,客户端需要向服务器请求颁发给自己数字证书 = 用服务器的公钥(另外一对中的)加密摘要得到的签名+客户端信息 + 客户端公钥。Https单向认证和双向认证

浏览器操作系统、或者应用自己内置了信任的根证书,浏览器或者客户端接收到服务器返回的的CA颁发的数字证书,从内置信任的根证书中获取CA的公钥,然后对服务器返回的数字证书中的签名进行解密得到摘要1,然后对服务器返回的数字证书中的内容进行取摘要运算得到摘要2,最后对比摘要1与摘要2是否相等,继而判断服务方是否是被CA认证的服务方。

2.2.1、SSL解决了通信中哪些问题?

  • 1、认证(Authentication):无法确认与我正在通信的人,就是我真正想通信的人

  • 2、泄露(privacy):与我通信的内容,被别人偷听

  • 3、篡改(data integrity):我接受到的的内容,并不是对方原始发送的数据

SSL不解决以下问题: 不可抵赖性(消息的发送者没办法不承认消息是自己发出的)。因为SSL并不对传输的数据做签名。但是SSL加上数字签名证书可以解决该问题。

2.2.2、检验双方的真实性

HTTPS使用了数字证书(身份认证机构盖在数字身份证上的一个章或印,或者说加在数字身份证上的一个签名),这一行为表示身份认证机构已认定这个人,证书的合法性可以向CA验证。客户端收到服务器的响应后,先向CA验证证书的合法性,如果校验不通过浏览器就会终止连接,并提示用户证书不安全。 数字证书的组成:

  • 证书颁发机构
  • 证书颁发机构签名(数字签名是什么?
  • 证书绑定的服务器域名
  • 证书版本、有效期
  • 签名使用的算法(非对称加密算法,RSA)
  • 公钥
2.2.3、数据的保密性

就是对数据进行加密,通常使用两种加密算法:对称加密非对称加密

对称加密: 加密和解密使用相同的密钥,有点是加解密速度快,缺点是密钥丢失后无法做到保密,常用的有AES、DES。 非对称加密: 有一对密钥,公钥(向所有人开放)和私钥(不对外开放)。公钥加密的数据只能私钥解密,私钥加密的数据只能公钥解密,利用这种特性可以用来校验数字签名。

HTTPS的解决方案是这样的:用非对称算法随机加密出一个对称密钥,然后双方用对称密钥进行通信。具体来说,就是客户端生成一个随机密钥,用服务器的公钥对这个密钥进行非对称加密,服务器用私钥进行解密,然后双方就用这个对称密钥来进行数据加密了。

2.2.4、数据的完整性

哈希算法可以将任意长度的数据转化成固定大小的字符串,并且该过程不可逆,利用这个特性做数据完整性的校验。

2.2.5、HTTPS完整过程大致如下两图

要点: 使用公钥对摘要加密得到签名,使用私钥解密签名得到公钥

为什么需要数字证书? 因为网络通信的双方都可能不认识,那么就需要第三方介绍,这就是数字证书。数字证书是由Certificate Athority(CA认证中心)颁发的。

2.2.6、为什么Charles能够抓取HTTPS报文?

通过上面的分析,我们知道HTTPS可以有效防止中间人攻击,但是CharlesFiddler是可以抓取HTTPS请求并解密的,它们是如何做到的呢?

Charles作为一个中间人代理,当浏览器和服务器通信时,Charles接收服务器的证书,但自己动态生成一张证书发送给浏览器,也就是说Charles作为中间代理在浏览器和服务器之间通信,所以通信的数据可以被Charles拦截并解密。由于Charles更改了证书,浏览器校验不通过会给出安全警告,必须安装Charles的证书后才能进行正常访问。

  • 1、客户端向服务器发起HTTPS请求

  • 2、Charles拦截客户端的请求,伪装成客户端向服务器进行请求

  • 3、服务器向“客户端”(实际上是Charles)返回服务器的CA证书

  • 4、Charles拦截服务器的响应,获取服务器证书公钥,然后自己制作一张证书,将服务器证书替换后发送给客户端。(这一步,Charles拿到了服务器证书的公钥)

  • 5、客户端接收到“服务器”(实际上是Charles)的证书后,生成一个对称密钥,用Charles的公钥加密,发送给“服务器”(Charles)

  • 6、Charles拦截客户端的响应,用自己的私钥解密对称密钥,然后用服务器证书公钥加密,发送给服务器。(这一步,Charles拿到了对称密钥)

  • 7、服务器用自己的私钥解密对称密钥,向“客户端”(Charles)发送响应

  • 8、Charles拦截服务器的响应,替换成自己的证书后发送给客户端

至此,连接建立,Charles拿到了 服务器证书的公钥 和 客户端与服务器协商的对称密钥,之后就可以解密或者修改加密的报文了。

HTTPS抓包的原理还是挺简单的,简单来说,就是Charles作为“中间人代理”,拿到了 服务器证书公钥 和 HTTPS连接的对称密钥,前提是客户端选择信任并安装Charles的CA证书,否则客户端就会“报警”并中止连接。这样看来,HTTPS还是很安全的。

2.2.7、如何阻止Charles读取HTTPS数据?

  • 方案一:对HTTPS传输的数据进行二次对称加密(对称秘钥不能泄露)
  • 方案二:使用双向认证,不仅客户端验证服务器证书的合法性,服务器也要验证客户端证书的合法性

参考资料

TCP和UDP的最完整的区别

SSL解决了通信中的哪些问题 ?

浅谈HTTPS通信机制和Charles抓包原理

HTTP TCP UDP Socket 关系的几个经典图

关注下面的标签,发现更多相似文章
评论