问题：TCP、UDP
TCP/UDP
|—— TCP：传输控制协议
传输层协议 |
|—— UDP：用户数据报协议
TCP与UDP的区别：
1.基于连接与无连接；(TCP在收发数据前，必须和对方建立可靠的连接)
2.对系统资源的要求（TCP较多，UDP少）；
3.UDP程序结构较简单；
4.流模式与数据报模式 ；
5.TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。
问题：HTTP和HTTPS
http的请求方式有哪些？
GET
POST
HEAD
PUT
DELETE
OPTIONS
http的GET和POST的区别？
GET的请求参数一般以?分割拼接到URL后面，POST请求参数在Body里面
GET参数长度限制为2048个字符，POST一般是没限制的
GET请求由于参数裸露在URL中，是不安全的，POST请求则是相对安全，之所以说是相对安全，是因为，如果POST虽然参数非明文，但如果被抓包，GET和POST一样都是不安全的。(HTTPS该用还是得用)
http的状态码
200 OK：请求成功，信息在返回的响应报文中
301 发生了网络重定向
400 Bad Request：一个通用差错代码，指示该请求不能被服务器理解
404 Not Found：被请求的文件不在服务器上
501、502：服务端有异常
505 HTTP Version Not Supported：服务器不支持请求报文使用的HTTP协议版本
<4开头的状态码通常是客户端的问题，5开头的则通常是服务端的问题>
http的连接建立流程
三次握手 Client Server 阶段
-------1.客户端发送SYN同步报文给服务端----------------> TCP
<--2.服务端收到同步(或连接建立)报文后，发送SYN+ACK报文--- TCP
---------3.客户端回应一个确认报文ACK----------------> TCP
//之后在这条tcp通道上请求和响应
-----------------比如客户端发送一个http请求报文--------> HTTP
<----服务端回应一个http响应报文----------------------- HTTP
//当在这条tcp通道上完成请求之后呢，需要进行四次挥手
四次挥手
------1.客户端主动发送连接断开(FIN)终止报文到服务端------> TCP
<----2.服务端收到终止报文后，发送确认(ACK)报文----------- TCP
//此时由客户端到服务端的连接就断开了，但是服务端到客户端可能还会传递数据也可以传
//此时处于半关闭状态
//如果需要完全关闭，应该找个时机由服务端向客户端发送终止报文
<------3.服务端发送FIN+ACK报文------------------------ TCP
------4.客户端回给服务端一个确认(ACK)报文--------------> TCP
http的连接为什么需要握手
对比一下 UDP 的通信流程和 TCP 的通信流程， 可以发现， 在 UDP 协议中， 是没有握手这个操作的。
这里就引出了 TCP 与 UDP 的一个基本区别， TCP 是可靠通信协议， 而 UDP 是不可靠通信协议。
TCP 的可靠性含义： 接收方收到的数据是完整， 有序， 无差错的。
UDP 不可靠性含义： 接收方接收到的数据可能存在部分丢失， 顺序也不一定能保证。
TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。 为了实现这个需求， 很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。
为什么需要三次握手而不是两次握手
假设客户端发送一个同步报文给服务端的时候响应超时，那么客户端启动了超时重传机制，就会给服务端重新发送一个新的同步报文，新的同步报文被服务端接受经过三次握手后建立了一次连接。此时，超时的响应到达了服务端，服务端接受到后会以为这是一次新的连接请求，会给客户端一个确认报文，如果之后两次握手，那么这次超时的连接请求就会被建立，因而会产生错误。
HTTPS
含义
HTTPS 协议：一般理解为HTTP+SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。
SSL 是指安全套接字层，简而言之，它是一项标准技术，可确保互联网连接安全，保护两个系统之间发送的任何敏感数据，防止网络犯罪分子读取和修改任何传输信息，包括个人资料。两个系统可能是指服务器和客户端（例如，浏览器和购物网站），或两个服务器之间（例如，含个人身份信息或工资单信息的应用程序）。
此举可确保在用户和站点之间，或两个系统之间传输的数据无法被读取。它使用加密算法打乱传输中的数据，防止数据通过连接传输时被黑客读取。这里所说的数据是指任何敏感或个人信息，例如信用卡号和其他财务信息、个人姓名和住址等。
TLS（传输层安全）是更为安全的升级版 SSL。由于 SSL 这一术语更为常用，因此我们仍然将我们的安全证书称作 SSL。有 ECC、RSA 或 DSA 三种加密方式。
HTTPS连接方式
加上备注版本：
加密
对称加密
有流式、分组两种，加密和解密都是使用的同一个密钥。即通过同一把秘钥进行加密，之后用同一把秘钥解密。
例如：DES、AES-GCM、ChaCha20-Poly1305等。
这就有一个问题：当一方生成了秘钥 K 之后得把 K 分享给另一方。但是穿越 Sin City 的道路危险中途很可能有人窃听到 K，窃听者就可以假扮双方中的任何一 方与另一方通信。这叫中间人攻击。
非对称加密
加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。如果加密用公钥，解密就用私钥。如果加密用私钥，解密就用公钥。
例如：RSA、DSA、ECDSA、 DH、ECDHE。
举例：
小明的信箱编号是11A，小红的信箱编号是11B。这些都是大家知道的，类似于11A,11B这样的就叫公钥。其中11A是小明的公钥，11B是小红的公钥。小明想给小红传送信件，只需要把写好的信件投到小红的信箱里面。被信箱保护的信件，就好比加密的信息。只有小红用她的钥匙才能打开。而小红的钥匙就是她的私钥。每个人都有一对密钥，一个公开，一个保密。A要给B发送信息，就用B的公钥加密信息然后发送给B。B得到了加密信息，用自己的密钥解开加密信息，得到明文信息。然后小明小红就可以没羞没臊的通信了。
问题：NSURLConnection与NSURLSession区别
NSURLSession与NSURLConnection 的不同主要表现在以下几方面:
1)NSURLConnection 是 iOS2.0后推出的
NSURLSession 是iOS7.0后推出的,用于代替 NSURLConnection.
2)下载任务方式
NSURLConnection 使用异步回调,先将数据下载到内存,等下载完毕后,再写入沙盒.如果文件很大,会导致内存暴涨; 并且,使用异步回调无法监听下载进度.
所以使用 NSURLConnection下载的时候,使用代理回调监听下载进度,并且下载过程中要手动管理内存,使用起来比较麻烦.
而使用NSURLSession的时候,block 和代理可以同时起作用,并且可以直接从文件系统上传、下载,不会出现内存暴涨的情况. 下载文件的时候,默认会将文件下载到沙盒的 tmp文件夹中,不会占多少用内存. 但是在下载完成后,会删除文件,所以要在下载完成或者其他需要的地方,增加保存文件的代码.
3)请求方式的控制
NSURLConnection实例化对象，实例化开始，默认请求就发送（同步发送），不需要调用start方法。而cancel 可以停止请求的发送，停止后不能继续访问，需要创建新的请求。
NSURLSession有三个控制请求的方法，取消（cancel），暂停（suspend），继续（resume），暂停后可以通过继续恢复当前的请求任务。
4)断点续传实现方式
NSURLConnection进行断点下载，通过设置访问请求的HTTPHeaderField的Range属性，开启运行循环，NSURLConnection的代理方法作为运行循环的事件源，接收到下载数据时代理方法就会持续调用，并使用NSOutputStream(或者通过文件指针)管道流进行数据保存。
NSURLSession进行断点下载，当暂停下载任务后，如果 downloadTask （下载任务）为非空，调用 cancelByProducingResumeData:(void (^)(NSData *resumeData))completionHandler 这个方法，这个方法接收一个参数，完成处理代码块，这个代码块有一个 NSData 参数 resumeData，如果 resumeData 非空，我们就保存这个对象到视图控制器的 resumeData 属性中。在点击再次下载时，通过调用
[ [self.session downloadTaskWithResumeData: self.resumeData]resume]方法进行继续下载操作。
经过以上比较可以发现，使用NSURLSession进行断点下载更加便捷。
- NSURLSession 可以设置配置信息
NSURLSession的构造方法
（sessionWithConfiguration: delegate:delegateQueue）中有一个 NSURLSessionConfiguration类的参数可以设置配置信息，其决定了cookie，安全和高速缓存策略，最大主机连接数，资源管理，网络超时等配置。
NSURLConnection不能进行这个配置，相比于 NSURLConnection 依赖于一个全局的配置对象，缺乏灵活性而言，NSURLSession 有很大的改进了。
NSURLSession可以设置三种配置信息，分别通过调用三个类方法返回配置对象：
+(NSURLSessionConfiguration *)defaultSessionConfiguration，
配置信息使用基于硬盘的持久化Cache，保存用户的证书到钥匙串,使用共享cookie存储；
+(NSURLSessionConfiguration *)ephemeralSessionConfiguration
配置信息和default大致相同。除了，不会把cache，证书，或者任何和Session相关的数据存储到硬盘，而是存储在内存中，生命周期和Session一致。比如浏览器无痕浏览等功能就可以基于这个来做；
+(NSURLSessionConfiguration *) backgroundSessionConfigurationWithIdentifier:(NSString *)identifier
配置信息可以创建一个可以在后台甚至APP已经关闭的时候仍然在传输数据的session。注意，后台Session一定要在创建的时候赋予一个唯一的identifier，这样在APP下次运行的时候，能够根据identifier来进行相关的区分。如果用户关闭了APP,IOS 系统会关闭所有的background Session。而且，被用户强制关闭了以后，IOS系统不会主动唤醒APP，只有用户下次启动了APP，数据传输才会继续。
6)NSURLSession 支持HTTP 2.0
问题：AFN是怎么使用RunLoop的
常驻线程知识补充
下面开始常驻线程
首先新建类继承NSThread
#import <Foundation/Foundation.h>
@interface XMGThread : NSThread
@end
#import "XMGThread.h"
@implementation XMGThread
- (void)dealloc
{
NSLog(@"%s", __func__);
}
@end
然后我们在控制器里如下写
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
//XMGThread继承NSThread，是为了重写dealloc看到线程消亡
XMGThread *thread; = [[XMGThread alloc] initWithTarget:self selector:@selector(run3) object:nil];
[thread start];
}
上述方法执行后，每一次点击都是一个新的线程去执行任务，执行完任务线程开始消亡，可以知道开销会很大。那尝试用同一个线程去试试，首先想到的是使用强引用引用thread，不让他消亡，如下
/** 线程对象 */
@property (nonatomic, strong) XMGThread *thread;
- (void)viewDidLoad {
[super viewDidLoad];
self.thread = [[XMGThread alloc] initWithTarget:self selector:@selector(run) object:nil];
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
[self.thread start];
}
- (void)run
{
NSLog(@"---------");
}
第一次点击很正常，但第二次点击就奔溃，奔溃打印如下
reason: '*** -[XMGThread start]: attempt to start the thread again'
意思就是已经消亡的线程不能重新开启。所以即使是强引用，执行完任务后线程还是会消亡。
尝试接着改造，让thread不消亡
/** 线程对象 */
@property (nonatomic, strong) XMGThread *thread;
- (void)viewDidLoad {
[super viewDidLoad];
self.thread = [[XMGThread alloc] initWithTarget:self selector:@selector(run) object:nil];
[self.thread start];
}
- (void)run
{
[[NSRunLoop currentRunLoop] addPort:[NSPort port] forMode:NSDefaultRunLoopMode];//给RunLoop添加port，也就是Source，让线程保活。如果RunLoop里面没有Source或Timer，RunLoop还是会结束运行。
[[NSRunLoop currentRunLoop] run]; //创建以及运行循环
//上面一句与下面的两种写法等同。想让一个RunLoop跑圈，首先要选择一种模式，其次模式里的Source或Timer不能为空，不然不会循环。
// [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
// [[NSRunLoop currentRunLoop] runUntilDate:[NSDate distantFuture]];
NSLog(@"---------"); 这句话是不会打印的，因为一直在上一句跑圈，然后执行这个线程里的任务。
}
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
//把self.thread的方法里加了运行循环，这个线程就活下来了，这个方法可以调用。每次点击都在self.thread线程里执行test方法
[self performSelector:@selector(test) onThread:self.thread withObject:nil waitUntilDone:NO];
}
- (void)test
{
NSLog(@"---------");
}
如上已经能做到线程保活了。
还有奇葩的保活方案，如下，改造下上面代码里的run方法， 其他代码照旧。
//这种改造是不行的，该线程一直忙着处理while (1)，不会管其他事情的。
- (void)run
{
while (1); // 当前线程永远在处理这行代码
NSLog(@"---------");
}
- (void)run
{
while (1) {//一直让NSRunLoop跑圈，当NSRunLoop跑圈时就会检测要不要处理事情，所以比上面单独的while (1);高级很多，也可以做到保活目的。但是不太推荐这种写法。
[[NSRunLoop currentRunLoop] run];
}
NSLog(@"---------");
}
afn 3.0之后开始使用NSURLSession
afn使用NSRunLoop开启了一条常驻线程
//AFN源码
+ (void)networkRequestThreadEntryPoint:(id)__unused object {
@autoreleasepool {
[[NSThread currentThread] setName:@"AFNetworking"];
NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
[runLoop run];
}
}
+ (NSThread *)networkRequestThread {
static NSThread *_networkRequestThread = nil;
static dispatch_once_t oncePredicate;
dispatch_once(&oncePredicate, ^{
_networkRequestThread = [[NSThread alloc] initWithTarget:self selector:@selector(networkRequestThreadEntryPoint:) object:nil];
[_networkRequestThread start];
});
return _networkRequestThread;
}
