iOS

必备知识架构-线程与网络-③网络

必备知识架构-线程与网络-③网络

[toc]

知识架构

iOS知识库

Android知识库

目录

九、在一个https连接的网站里，输入账号密码点击登录后，到服务器返回这个请求前，中间经历了什么

< 返回目录

回答这个问题，我们必须要先了解，一次完整的HTTP请求过程，大概是什么样的。

点击登录和服务器返回这个请求前，中间发生的起始就是一个域名解析和一次完整的http请求过程。

域名解析：即请求DNS服务器，进行域名解析。DNS服务器负责将你的网络地址解析成IP地址，这个IP地址对应网上一台机器；

而一次完整的HTTP请求过程，下面介绍之。

1、一次完整的HTTP请求过程

一次完整的HTTP请求过程如下图所示：

一次完整的HTTP请求过程
详情可参考：一次完整的HTTP请求过程

HTTP与HTTPS的区别

http和https使用的是完全不同的连接方式。

区别统计：

①HTTP是不安全的(它的信息使用明文传输)，而HTTPS是安全的(会进行加密)；

②使用的端口也不同，http使用的是80端口，https使用的是443端口。

③HTTP无需证书，而HTTPS需要认证证书。

在网络模型中，HTTP工作于应用层，而HTTPS工作在传输层；

2、TCP三次握手

一个故事让大家明白为什么会有tcp三次握手

1
2
3
4
5
> 敌人封锁江面, 我方间谍和联络员只能通过电报机隔着江面交流. 但是那时的电报机质量不稳定, 有可能会出现失灵的情况. 所以就出现了如下对话:
间谍: 联络员, 你能收到我发的话么? 你要是能收到, 就说明我这个电报机可以发电报.
联络员: 间谍, 我收到你发的话了, 这说明我的电报机可以收. 但是我不确定我的电报机能不能发, 你能收到我发的这句话么? 你要是能收到, 就说明我的电报机是可以发电报的. 
间谍: 联络员, 我收到你的话了. 我的电报机也是能发能收, 我们可以正式交流情报了.
>

TCP三次握手过程

第一次握手： 客户端给服务器发送一个含有同步序列号SYN 报文。

主机A通过向主机B 发送一个含有同步序列号SYN的标志位的数据段给主机B ,向主机B 请求建立连接,通过这个数据段,主机A告诉主机B 两件事:我想要和你通信;你可以用哪个序列号作为起始数据段来回应我.

第二次握手： 服务器收到 SYN 报文之后，会应答一个 SYN+ACK 报文。

主机B 收到主机A的请求后,用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A,也告诉主机A两件事:我已经收到你的请求了,你可以传输数据了;你要用哪佧序列号作为起始数据段来回应我

第三次握手： 客户端收到 SYN+ACK 报文之后，会回应一个 ACK 报文。

主机A收到这个数据段后,再发送一个确认应答,确认已收到主机B 的数据段:”我已收到回复,我现在要开始传输实际数据了,这样三次握手就完成了,主机A和主机B 就可以传输数据了.

服务器收到 ACK 报文之后，三次握手建立完成。

附：

TCP三次握手的作用是为了确认双方的接收与发送能力是否正常。

握手过程中传送的包里正常不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据

但其实第三次握手的时候，是可以携带数据的。也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

3、TCP四次挥手

1
2
3
4
5
6
> 举个栗子：把客户端比作男孩，服务器比作女孩。通过他们的分手来说明“四次挥手”过程。
> "第一次挥手"：日久见人心，男孩发现女孩变成了自己讨厌的样子，忍无可忍，于是决定分手，随即写了一封信告诉女孩。
> “第二次挥手”：女孩收到信之后，知道了男孩要和自己分手，立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，全部还给你！男孩收到女孩的第一封信之后，明白了女孩知道自己要和她分手。随后等待女孩把自己的东西收拾好。
> “第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，于是再次写信给男孩：你的东西我整理好了，快把它们拿走，从此你我恩断义绝！
> “第四次挥手”：男孩收到女孩第二封信之后，知道了女孩收拾好东西了，可以正式分手了，于是再次写信告诉女孩：我知道了，这就去拿回来！
>

4、为什么TCP建立连接要进行3次握手,而断开连接要进行4次？

35 张图解：被问千百遍的 TCP 三次握手和四次挥手面试题

详解 TCP 连接的“ 三次握手 ”与“ 四次挥手 ”/为什么“握手”是三次，“挥手”却要四次？

建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。

释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。

所以是“三次握手”，“四次挥手”。

tcp_三次握手tcp_四次挥手

四次握手与三次握手

四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。

为什么需要四次挥手。

  • 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
  • 服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

5、TCP两次握手会出现什么问题

《计算机网络》（谢希仁 译）中讲了原因：
1.采用两次握手，那么若Client向Server发起的包A1如果在传输链路上遇到的故障，导致传输到Server的时间相当滞后，在这个时间段由于Client没有收到Server的对于包A1的确认(如果有确认，即Server有收到的话，会发送回一个B1包)，那么就会重传一个包A2(应该是等超时了)，假设服务器正常收到了A2的包，然后返回确认B2包。由于没有第三次握手，这个时候Client和Server就被认为是已经建立连接，可以传输数据了。

接着假设Client发送的第一个A1包随后在链路中传到了Server，对于Server来说这是一个新连接请求，然后Server又为这个连接申请资源，返回B1包，但是由于Client现在用的是A2包，A1包是无效的，Client对于返回的B1包也不会去理会，即后面建立的这个连接其实是没用的(相当于“僵尸”的连接)，Server一直为这个连接维持着资源，造成资源的浪费。

所以采用两次握手，有可能会浪费Server的网络资源。

TCP的三次握手最主要是防止已过期/失效的连接再次传到被连接的主机。

为什么要进行第三次握手？

为了防止服务器端开启一些无用的连接增加服务器开销以及防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

十、TCP与UDP

< 返回目录

1、TCP与UDP的区别

TCP（Transmission Control Protocol，传输控制协议）是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接。
UDP（User Data Protocol，用户数据报协议）是与TCP相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！
UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。

TCP与UDP的区别：

1
2
3
4
5
1. 基于连接与无连接；
2. 对系统资源的要求（TCP较多，UDP少）；
3. UDP程序结构较简单；
4. 流模式与数据报模式 ；
5. TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。

2、为什么说UDP是不可靠的？

答：UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议
也正由于上面的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。

也正由于上面的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。

所以采用TCP传输协议的MSN比采用UDP的QQ传输文件慢，
但并不能说QQ的通信是不安全的，因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，即使是这样，UDP因为在底层协议的封装上没有采用类似 TCP的“三次握手”而实现了TCP所无法达到的传输效率。

3、移动端IM系统的协议选型：UDP还是TCP？

移动端IM系统的协议选型：UDP还是TCP？

TCP还是UDP？长连接如何实现？如何实现心跳机制？心跳的间隔如何确定？这些问题都是讨论移动端IM、消息推送等类似话题时，几乎一定被问到的问题。

个人认为，更恰当的方式应该是：两种通信协议同时使用，各有侧重。UDP用于保持大量终端的在线与控制，应用与业务则通过TCP去实现。这个和FTP服务控制与数据分离，采取不同的连接，有异曲同工之处。
事实上，这个也是即时通讯巨头QQ所采用的方式。早期的时候，QQ还是主要使用TCP协议，而后来就转向了采用UDP的方式来保持在线，TCP的方式来上传和下载数据。现在，UDP是QQ的默认工作方式，表现良好。相信这个也被沿用到了微信上。
简单的考证：登录PC版QQ，关闭多余的QQ窗口只留下主窗口，并将其最小化。几分钟过后，查看系统网络连接，会发现QQ进程已不保有任何TCP连接，但有UDP网络活动。这时在发送聊天信息，或者打开其他窗口和功能，将发现QQ进程会启用TCP连接。

十一、网络数据缓存

< 返回目录

iOS开发网络篇—数据缓存

RTMP VS RTSP

RTMP（Real-Time Messaging Protocol）和RTSP（Real-Time Streaming Protocol）都是用于流媒体数据传输的协议，但它们在设计和应用上有一些关键的区别。

  • RTMP是基于TCP的协议，RTSP是一种基于TCP或UDP的网络控制协议。
  1. 延迟：
    • RTMP的延迟通常在3-30秒，适合于对实时性要求不是极高的应用。
    • RTSP的延迟通常在2-5秒，适合于对实时性要求较高的应用。
  2. 编解码器支持：
    • RTMP通常支持H.264视频编码和AAC音频编码。
    • RTSP支持多种视频编码，包括H.265、H.264、VP9等。

在选择使用RTMP还是RTSP时，需要根据具体应用场景、对实时性的要求、客户端兼容性以及安全性需求来决定。例如，如果需要与HTML5兼容且对实时性要求不高，可能会选择基于HTTP的流媒体协议如HLS或DASH。如果需要低延迟和复杂的交互控制，则可能会选择RTSP。而RTMP可能更适合那些已经建立在Flash基础上的旧系统。

1、RTSP

RTSP（Real-Time Streaming Protocol）和TCP、UDP都是网络协议，它们在数据传输和流媒体领域中扮演着重要的角色。下面我将分别介绍它们的特点和用途：

  1. RTSP（Real-Time Streaming Protocol）：
    • 定义：RTSP是一种网络控制协议，用于控制流媒体服务器上的媒体流。它允许客户端发出播放、暂停、停止等控制命令。
    • 用途：RTSP常用于视频监控系统中，通过它可以实现对视频流的控制，如请求视频流的开始、停止、快进、倒退等。
    • 特点：
      • 基于TCP或UDP，通常使用TCP来保证控制消息的可靠传输。
      • 它不传输媒体本身，而是控制媒体流的传输，媒体数据通常通过RTP（Real-time Transport Protocol）传输。
      • 支持多种媒体类型，包括音频和视频。
  2. TCP（Transmission Control Protocol）：
    • 定义：TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。
    • 用途：TCP广泛应用于需要可靠传输的应用中，如网页浏览（HTTP）、文件传输（FTP）、邮件传输（SMTP）等。
    • 特点：
      • 确保数据包按顺序到达，如果数据包丢失，会重新发送。
      • 建立连接需要三次握手，断开连接需要四次挥手，这增加了一定的延迟。
  3. UDP（User Datagram Protocol）：
    • 定义：UDP是一种无连接的传输层协议，它在IP协议的基础上提供一种简单的数据传输服务。
    • 用途：UDP适用于对实时性要求高的应用，如视频会议、在线游戏、实时监控等。
    • 特点：
      • 不保证数据包的顺序、完整性或可靠性，如果数据包丢失，不会重发。
      • 没有建立连接的过程，发送数据前不需要握手，因此延迟较低。
      • 适用于那些可以容忍一定丢包率的应用，或者应用层自己实现数据的重传和顺序控制。

在实际应用中，RTSP通常与RTP（Real-time Transport Protocol）配合使用，RTSP用于控制媒体流，而RTP用于实际传输媒体数据。RTP可以选择在TCP或UDP上运行，但在流媒体传输中，UDP更常见，因为它的低延迟特性更适合实时媒体流的传输。而TCP则因其可靠性，适用于需要确保数据完整性的场景。

2、RTP

实时传输协议（RTP）是一种网络协议，专门设计用于在互联网上传输音频和视频数据。它通常与实时传输控制协议（RTCP）一起使用，后者用于监控数据传输的质量和提供反馈。RTP 被设计为一个基于数据包的协议，将媒体流分成数据包进行传输，每个数据包都有一个序列号，使得接收方能够以正确的顺序重新组合数据包。此外，RTP 还包括一个时间戳，允许接收器同步音频和视频流。

RTP 通常用于各种实时音频和视频传输的应用，如IP语音（VoIP）、视频会议、流媒体和广播电视等。它被广泛支持，并经常与其他协议如RTSP和SIP结合使用，以在互联网上传输音频和视频内容。

RTP 数据包的结构包括一个固定头部和可选的扩展头部，以及实际的媒体数据。

网络 | http常见错误码

  • HTTP状态码介绍，以及HTTP错误代码的故障修复？

    HTTP 状态码是一个客户发出请求时候，WEB服务器返回给客户的一个状态回应，常见HTTP状态有以下五类：

    1.信息代码：1xx，

    2.成功代码：2xx，

    3.重定向：3xx，

    4.客户端错误：4xx，

    5.服务器错误：5xx

    其中，我们需要关注的是客户端和服务器端错误代码，即4xx和5xx代码以及这些代码的常见解决方案。

    客户端错误，从400到499编码的客户端错误是由客户端引起的某些错误导致的，该客户端是Web浏览器、curl命令或postman等其他服务器测试软件发出的请求等。

    服务器错误，当服务器发生错误或服务器识别出无法处理请求时，将发送代码为500到599的服务器错误。

常见状态码：

一些常见的状态码为：

  • 200 – 服务器成功返回网页

  • 302

  • 304（未修改）

  • 404 – 请求的网页不存在

  • 503 – 服务器超时

1xx（临时响应）

表示临时响应并需要请求者继续执行操作的状态代码。

2xx （成功）

表示成功处理了请求的状态代码。

3xx （重定向）

表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。

4xx（请求错误）

这些状态代码表示请求可能出错，妨碍了服务器的处理。

5xx（服务器错误）

这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。

AFNetworking 302 重定向

所有的AF请求都会在post get等请求前执行下面这个方法，所以只需重写这个方法就能拦截请求

1
2
3
4
5
6
@interface AFURLSessionManager ()
// 省略一堆代码
@property (readwrite, nonatomic, copy) AFURLSessionTaskWillPerformHTTPRedirectionBlock taskWillPerformHTTPRedirection;
// 省略一堆代码

@end

使用举例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
manager = [AFHTTPSessionManager manager];
[manager setTaskWillPerformHTTPRedirectionBlock:^NSURLRequest * _Nonnull(NSURLSession * _Nonnull session, NSURLSessionTask * _Nonnull task, NSURLResponse * _Nonnull response, NSURLRequest * _Nonnull request) {
            NSHTTPURLResponse *resPonse = (NSHTTPURLResponse *)response;
           //1、如果要忽略重定向
          /*
            if (resPonse.statusCode == 302){
                return nil;
            }else {//正常请求
                return request;
            }
             */
         // 2、通过重定向url去获取数据
            if (resPonse.statusCode == 302){//如果响应code==302 就是重定向
                NSMutableURLRequest *res = [NSMutableURLRequest requestWithURL:request.URL];
              //通过抓包发现请求头不见了 所以在这里添加请求头，如果没有这个需求的可以忽略
                NSMutableDictionary *headers = [NSMutableDictionary dictionaryWithDictionary:request.allHTTPHeaderFields];
                NSString *valueStr = [NSString stringWithFormat:@" %@",localToken];
                [headers setObject:valueStr forKey:@"Authorization"];
                res.allHTTPHeaderFields = headers;

                return res;
            }else {//正常请求
                return request;
            }
}];

常见笔试/面试题

< 返回目录

1、简要说下Http通信协议的原理，与Socket协议的区别有哪些？

答：HTTP协议：简单对象访问协议，对应于应用层，HTTP协议是基于TCP连接的

tcp协议：对应于传输层

ip协议：对应于网络层

TCP/IP是传输层协议，主要解决数据如何在网络中传输；而HTTP是应用层协议，主要解决如何包装数据。

Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，才能使用TCP/IP协议。

http连接：http连接就是所谓的短连接，即客户端向服务器端发送一次请求，服务器端响应后连接即会断掉；

socket连接：socket连接就是所谓的长连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉；但是由于各种环境因素可能会是连接断开，比如说：服务器端或客户端主机down了，网络故障，或者两者之间长时间没有数据传输，网络防火墙可能会断开该连接以释放网络资源。

2、cookie 和session 的区别：

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、安全性：
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗。
考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能
考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5、所以个人建议：
将登陆信息等重要信息存放为SESSION
其他信息如果需要保留，可以放在COOKIE中

END

< 返回目录