网络相关
1.HTTP协议
超文本传输协议，它是客户端和服务器进行数据交互的一个重要的协议。
请求的组成部分
- 1.请求行:(请求类型 , URL, 版本号)
A请求类型(get 和 post ，HEAD，delete，connection..)
B URL统一资源定位符
C 版本号：HTTP1.1 - 2.请求头：一个个的键值对。
- 3.请求数据: (get请求 是没有请求数据的，他的请求数据是在URL里面拼接的)
响应的组成部分
- 1.响应行:A、(URL)，B、(状态码):(no find 404)
1XX 请求已经接受，需要继续处理2XX一般就是请求成功
3XX重定向 4XX 请求失败 —客户端问题 5XX服务器问题 - 2.响应头: 一个个键值对
- 3.响应数据:
Get请求和Post请求的区别
首先Get请求是得到数据，Post请求是发送数据
服务器解析方式/请求数据/长度限制/安全性/使用场合
1.服务器解析方式：Get是以字符串的形式进行解析，Post请求是封装成字典通过key-value，以表单的形式解析
2.get请求没有请求数据，它的请求数据是放在URL后面拼接的
3.get请求的URL有长度限制且跟浏览器有关（一般是1024KB），Post请求理论上没有限制。
4.从安全性的角度来看，Post理论上比Get安全 取决于加密方式
5.使用场合：一般情况下：从服务器上面取东西用Get；上传到服务器用Post。
2.TCP建立连接三次握手🤝，断开连接几次
建立TCP需要三次握手才能建立，而断开连接则需要四次握手
ACK:确认 FIN:
建立连接
- 首先Client端发送连接请求报文
- Server接收连接后回复ACK报文，并为这次连接分配资源。
- Client端接收到ACK报文后也向Server发送ACK报文，并分配资源，这样TCP连接就建立了。
断开连接
断连接端可以是Client端，也可以是Server端
- 客户端向服务器发送fin用来关闭服务器和客户端的数据传送；
- 服务器接收到fin并向服务器发送ack；
- 服务器关闭与客户端的连接，并发送fin给客户端；
- 客户端发送ack报文确认
通俗例子：
三次握手：
A:“喂，你听得到吗？”A->SYN_SEND
B:“我听得到呀，你听得到我吗？”应答与请求同时发出 B->SYN_RCVD | A->ESTABLISHED
A:“我能听到你，今天balabala……”B->ESTABLISHED
四次挥手：
A:“喂，我不说了。”A->FIN_WAIT1
B:“我知道了。等下，上一句还没说完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2
B:”好了，说完了，我也不说了。”B->LAST_ACK
A:”我知道了。”A->TIME_WAIT | B->CLOSED
A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED
3.TCP&UDP
TCP-传输控制协议
- 建立连接，形成传输数据的通道
- 在连接中可进行大数据传输，数据大小不做限制
- 通过三次握手完成连接，是可靠协议，安全送达
必须建立连接，效率会降低
UDP-用户数据报协议
- 将数据源和目的封装到数据包中，不需要建立连接
- 每个数据包的大小限制在64K之内
- 因为不需要连接，因此是不可靠协议
不需要建立连接，速度快
4.AFN3.0与2.0区别
发展历程
AFNetworking 2.0开始使用NSURLConnection的基础API ，以及较新基于NSURLSession的API的选项。
AFNetworking 3.0现已完全基于NSURLSession的API，这降低了维护的负担，同时支持苹果增强关于NSURLSession提供的任何额外功能。
废弃与新增
下面的类已从AFNetworking 3.0中废弃
AFURLConnectionOperation
AFHTTPRequestOperation
AFHTTPRequestOperationManager
依次被下面三个类代替了，同时请求方法也跟着改变了
AFURLSessionManager
AFHTTPSessionManager
AFNetworkReachabilityManager
优势
- NSURLSession提升了网络连接速度
- Session采用了共享，而非每次都新建，降低最大并发数
5.AFN2.0常驻线程
AFN2.0里面把每一个网络请求的发起和解析都放在了一个线程里执行。正常来说，一个线程执行完任务后就退出了。开启runloop是为了防止线程退出。一方面避免每次请求都要创建新的线程；另一方面，因为connection的请求是异步的，如果不开启runloop，线程执行完代码后不会等待网络请求完的回调就退出了，这会导致网络回调的代理方法不执行。
这是一个单例，用NSThread创建了一个线程，并且为这个线程添加了一个runloop，并且加了一个NSMachPort，来防止runloop直接退出。 这条线程就是AF用来发起网络请求，并且接受网络请求回调的线程，仅仅就这一条线程
6.AFN3.x为什么不再需要常驻线程？
NSURLConnection的一大痛点就是：发起请求后，这条线程并不能随风而去，而需要一直处于等待回调的状态。
苹果也是明白了这一痛点，从iOS9.0开始 deprecated 了NSURLConnection。 替代方案就是NSURLSession。
self.operationQueue = [[NSOperationQueue alloc] init];
self.operationQueue.maxConcurrentOperationCount = 1;
self.session = [NSURLSession sessionWithConfiguration:self.sessionConfiguration delegate:self delegateQueue:self.operationQueue];
为什么说NSURLSession解决了NSURLConnection的痛点，从上面的代码可以看出，NSURLSession发起的请求，不再需要在当前线程进行代理方法的回调！可以指定回调的delegateQueue，这样我们就不用为了等待代理回调方法而苦苦保活线程了。
同时还要注意一下，指定的用于接收回调的Queue的maxConcurrentOperationCount设为了1，这里目的是想要让并发的请求串行的进行回调。
