iOS开发需掌握的网络基础

HTTP

超文本传输协议
请求报文格式


请求报文

响应报文格式


响应报文

常用的请求方式

POST GET HEAD PUT DELETE OPTIONS

POST 与 GET的区别

POST:非安全、非幂等、不可缓存
GET:安全的、幂等的、可缓存

  1. 安全的:不引起服务端任何状态变化。有:GETHEADOPTIONS
  2. 幂等的:一次请求与多次执行结果相同。有:GETPUTDELETE
  3. 可缓存:请求可以在网络路径上去缓存。有:GETHEAD

状态码

常见状态码

  1. 1XX
  2. 2XX: 200 请求成功
  3. 3XX: 301,302 网络重定向
  4. 4XX: 401,404 一般表示请求可能存在问题
  5. 5XX:502,501 一般表示服务端存在异常

完整的HTTP过程

HTTP请求

HTTP请求会先三次握手建立TCP连接,然后发送HTTP请求,与接收响应,最后四次挥手断开连接。

HTTP特点

无连接,无状态
1.无连接:每次连接只处理一个请求,一次应答完毕后断开连接。
解决方案:HTTP持久连接。
头部字段
Connection:keep-alive 是否采用持久连接
time:10 连接持续时间
max:10 做多发生多少次HTTP请求
判断持久连接结束
Content-Length长度
chunked是否为空,为空结束

  1. 无状态:对于交互场景没有记忆能力。
    解决方案:cookie/session

Charles抓包原理

中间人攻击:
中间设备截获客户端的HTTP请求,假装客户端像服务端请求,获取到服务端的响应,再返回给客户端。中间人可以对请求与响应进行修改再进行发送。


HTTPS

HTTPS = HTTP+SSL/TLS
HTTPS是安全的HTTP,安全是由SSL/TLS(应用层之下,传输层之上)的协议保证的。

HTTPS连接建立流程

HTTPS连接建立流程
  1. 客户端将TLS版本号,支持的加密算法列表,随机数C传给服务端。
  2. 服务端从支持的算法列表中确定加密算法,带上随机数S与证书返给客户端。
  3. 客户端验证证书。
  4. 客户端将随机数C,随机数S,预主秘钥等组装会话秘钥。
  5. 客户端通过公钥对预主秘钥加密,传输给服务端。
  6. 服务端通过私钥解密预主秘钥。
  7. 服务端组装会话秘钥。
  8. 客户端与服务端发送加密的握手消息,验证通道连接。
    会话秘钥:对称加密中使用。

HTTPS使用的加密手段

  1. 对称加密: 后续通讯过程中使用。
    服务端与客户端使用相同的公钥进行加密解密。
  2. 非对称加密: 连接建立过程中使用。
    客户端通过公钥加密与解密。
    服务端通过私钥加密与解密。

TCP与UDP

TCP与UDP区别

UDP
特点:无连接,尽最大努力交付,面向报文。
功能:复用、分用、差错检测
TCP
特点:面向连接、可靠传输、面向字节流、流量控制、拥塞控制

  1. 面向连接:传输前需要建立连接,三次握手;传输结束,断开连接,四次握手。
    三次握手
  • 客户端发送握手信号SYN
  • 服务端接收到握手信号SYN,发送SYN与确认信号ACK
  • 客户端发送确认信号ACK
    四次挥手
  • 客户端发送结束信号FIN
  • 服务端发送确认信号ACK
  • 客户端接收到确认信号ACK,断开客户端到服务端的连接
  • 服务端发送结束信号FIN与确认信号ACK
  • 客户端发送确认信号ACK
  • 服务端接收到确认信号断开服务端到客户端的连接
  1. 可靠传输:信号无差错、不丢失、不重复、按序到达
  2. 流量控制:对传输的字节流大小进行控制。
  3. 拥塞控制: 慢开始、拥塞避免;快恢复、快重传

为什么要三次握手、四次挥手

  • 三次握手



    如果第一次SYN超时,客户端会触发超时重传,发送新的SYN,如果这是连接成功,超时的SYN这时到达服务端,服务端会认为客户端又想建立一个新的连接,如果只有两次握手,就会建立两个连接。而三次握手,客户端就可以忽略第二次的握手信号,避免重复建立连接。-

  • 四次握手
    TCP的连接通道是全双工的,需要分别断开两个端点的连接。

如何保障可靠传输

  • 超时重传


    超时重传

    客户端在一定时间范围内,未收到确认信号,就会重传报文。

  • 确认丢失、确认迟到


    确认丢失、确认迟到

    确认信号因为网络原因未到达客户端,客户端再次发送相同报文,服务端会对重复报文进行丢弃,并重新发送确认信号。当旧的确认信号又到达后,客户端继续现有操作,忽略这个确认信号。

流量控制实现

滑动窗口协议

拥塞控制实现

慢开始
  1. 从发送1个数据包开始,指数增长
  2. 达到设定阈值后,线性增长传送包的大小
  3. 当数据超时后,将阈值设为该值的一半重新开始


    快恢复

    当超时后,将阈值设为一半,开始线性增长

DNS

DNS查询方式

递归查询


递归查询

逐级向上查找
迭代查找


迭代查找

去可能有的服务器查找

DNS劫持

DNS劫持与HTTP无关。
DNS解析发生在HTTP之前。
DNS解析使用UDP数据报,端口号53


DNS劫持

发送错误的ip,访问错误的网站
解决DNS劫持
httpDNS:使用HTTP协议向DNS服务器请求,80端口,不使用53端口。
长连接

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,427评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,551评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,747评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,939评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,955评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,737评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,448评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,352评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,834评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,992评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,133评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,815评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,477评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,022评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,147评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,398评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,077评论 2 355

推荐阅读更多精彩内容