Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

iOS探索:网络相关

0
0
超文本传输协议 请求报文
iOS探索:网络相关

我们来看一下请求报文的格式,首先是请求行,请求行包括方法、URL、协议文本,方法常见的有GET/POST,URL就是我们的请求地址,协议文本一般是HTTP1.1版本

然后再看一下请求头,头部字段都是以key:value的形式组合在一起的,由多个首部字段名构成首部字段区域

之后是我们的实体主体,一般在GET请求中没有实体主体,而在POST请求中一般会带有实体主体

响应报文
iOS探索:网络相关

首先是版本,然后是状态码,还有状态码的描述,我们称之为短语,然后下面跟请求报文一致,由此组成响应报文

HTTP的请求方式

GET

POST

HEAD

PUT

DELETE

OPTIONS

GET和POST方式的区别

一般大家都知道的是:

GET请求参数是以?分割拼接到URL后面的,POST请求参数实在Body里面的

GET参数长度限制2048个字符,POST一般没有该限制

GET请求不太安全,POST请求比较安全

但是从语义的角度来比较的话,是这样的:

GET:获取资源,是安全的、幂等的、可缓存的

POST:处理资源,是非安全的、非幂等的、不可缓存的

对应的解释

1、安全性:不应该引起Server端的任何状态变化,比如说我们用GET请求多次去Server端去获取数据,不会引起Server的一个状态变化,安全性的请求包括:GET、HEAD、OPTIONS

2、幂等性:同一个请求方法执行多次和执行一次的效果完全相同,比如说我们用GET请求多次去Server端去获取数据,执行的效果是完全相同的,这里需要注意的是执行的效果,幂等性的请求包括:GET、PUT、DELETE

3、可缓存性:请求是否可缓存,我们一般在发起一个HTTP请求的过程中,传递的链路我们是不确定的,虽然说实在一条TCP连接上,但是网络路径在接触或者通过网关包括一些代理到达我们的Server端,在这上面会涉及到方方面面的内容,往往对于一些代理服务器会有缓存,而这种缓存性是官方的一种规范,即可以遵守也可以不遵守,大多数情况会遵守,所以在GET请求会有相对应的缓存,可缓存性的请求包括:GET、HEAD

状态码

1XX:通知

2XX:成功

3XX:重定向

4XX:客户端错误

5XX:服务端错误

连接建立流程 三次握手

首先是客户端发送一个SYN的请求报文给服务端,请求建立连接

当服务端收到报文后,服务端会返回给客户端一个同步ACK的报文

当客户端收到报文后,会返回给服务端一个ACK报文,完成三次握手

四次挥手

如果是客户端发起主动断开,客户端会发送一个FIN终止报文给服务端

服务端会返回给客户端一个ACK确认报文,这时客户端与服务端的连接就断开了,但是服务端到客户端这个方向,可能还会传递数据,在一个合适时机,服务端会向客户端请求断开连接

服务端想要断开连接的时候,会向客户端发送FIN终止报文

然后客户端会回给服务端一个确认报文,此时完成服务端与客户端的连接断开

HTTP的特点

无连接,补偿方案为HTTP的持久连接

无状态,补偿方案为Cookie/Session

HTTPS与网络安全

HTTPS = HTTP + SSL/TLS

HTTPS就是在原有HTTP基础上,在应用层下面,传输层上面插入了一个SSL/TLS协议中间层,为我们实现一个安全的网络机制,也就是说HTTPS是安全的HTTP

HTTPS连接建立流程

首先由客户端向服务端发送一个报文,这个报文包括三部分,一个是客户端支持的TLS版本,客户端支持的加密算法,以及一个随机数C

然后服务端返回一个握手报文消息,包括一个商定的加密算法,随机数S还有一个服务端的证书

客户端收到这条报文后,首先会验证证书,之后会组装会话秘钥,这个秘钥主要通过前面的随机数C和随机数S以及一个预主秘钥进行会话秘钥的组装

然后客户端会通过服务端的公钥对预主秘钥进行加密传输,之后服务端通过私钥解密得到预主秘钥,最后服务端会通过前面的随机数C、随机数S以及解密得到的预主秘钥组装会话秘钥

之后再由客户端向服务端发送一个加密的握手消息,服务端发送一个加密的握手消息,来验证是否加密完成

TCP/UDP 传输层协议

TCP:传输控制协议

UDP:用户数据报协议

UDP(用户数据报协议)

特点:

1、无连接

2、尽最大努力交付

3、面向报文,既不合并,也不拆分

功能包括:

1、复用

2、分用

3、差错检测

TCP(传输控制协议)

特点:

1、面向连接

2、可靠传输(无差错,不丢失,不重复,按序到达)

3、面向字节流

4、流量控制

5、拥塞控制

DNS解析

域名到IP地址的映射,DNS解析请求是采用UDP数据报,且明文


iOS探索:网络相关
DNS解析查询方式

递归查询 (一层一层的查询)

迭代查询 (返回结果找对应查询)

DNS劫持问题

当客户端发送域名去DNS服务器去查询时,由于是UDP数据包并且明文,就会被窃听,这时如果有一个钓鱼服务器劫持了这次查询,返回给你一个错误的IP,这时你就会访问到一个错误的网页

这里还需要注意一个点:就是DNS劫持和HTTP是完全没有关系的,因为DNS解析是发生在HTTP建立连接之前,并且DNS解析请求使用的事UDP数据报,端口号53

那么如何解决DNS劫持问题呢?

httpDNS:DNS解析请求使用的事UDP数据报,端口号53,解决方案是使用HTTP协议向DNS服务器的80端口进行请求,不会产生正常的DNS解析,也就不会出现DNS的劫持问题

长连接:在客户端和服务端之间建立一个长连服务,也就是一个代理服务器,在客户端和代理服务器之前建立长连通道,然后再代理服务器和服务端之间通过内网专线进行内网DNS解析,然后进行请求

DNS解析转发问题

简单一句话,就是我们客户端发送请求时,我们的DNS服务器可能为了节省资源等原因,会转发给其他的DNS服务器,会出现跨网访问,可能会慢一点

Session/Cookie

HTTP协议无状态特点的补偿

Cookie

主要是用来记录用户状态,区分用户;状态保存在客户端,客户端发送的Cookie在http请求报文的Cookie首部字段中,服务端设置http响应报文的Set-Cookie首部字段

修改Cookie

新Cookie覆盖旧Cookie

覆盖规则:name、path、domain等需要与原Cookie保持一致

删除Cookie

新Cookie覆盖旧Cookie

覆盖规则:name、path、domain等需要与原Cookie保持一致

设置Cookie的expires = 过去的一个时间点,或者maxAge = 0

怎样保证Cookie的安全性

对Cookie进行加密处理

只在https上携带Cookie

设置Cookie为httpOnly,防止跨站脚本攻击

Session

也是用来记录用户状态,区分用户;状态保存在服务端 Session需要依赖于Cookie机制

至此iOS基础相关的内容暂时告一段落,写的可能并不是特别详细,也会有很多的瑕疵,也多谢各位对文章问题的指出,接下来会写一些数据结构与算法相关的内容,届时希望大家可以共同探讨,共同进步

Viewing all articles
Browse latest Browse all 12749

Latest Images

Trending Articles





Latest Images