Alamofire初探

一. Alamofire概述

对于使用Objective-C的开发者，一定非常熟悉AFNetworking这个网络框架。在苹果推出的Swift之后，AFNetworking的作者专门用Swift来编写一个类似AFNetworking的网络框架，称为Alamofire。Alamofire地址
因为Alamofire是对苹果URLSesstion的封装,所以先来了解下URLSesstion的基础

二. URLSesstion基础

URLSession.shared.dataTask(with: url) { (data, response, error) in
            if error == nil {
                print("请求成功\(String(describing: response))" )
            }
        }.resume()

此过程省略了一个重要的东西：URLSessionConfiguration

open class var `default`: URLSessionConfiguration { get }
open class var ephemeral: URLSessionConfiguration { get }
    @available(iOS 8.0, *)
    open class func background(withIdentifier identifier: String) -> URLSessionConfiguration

URLSessionConfiguration有三种模式

• default：默认模式，通常使用这种模式就够了，default模式下系统会创建一个持久化的缓存并在用户的钥匙串中存储证书
• ephemeral:系统没有任何持久性存储，所有内容的生命周期与session相同，当session无效时，所有内容自动释放

        let configuration1 = URLSessionConfiguration.default
        let configuration2 = URLSessionConfiguration.ephemeral
        print("沙盒大小: \(String(describing: configuration1.urlCache?.diskCapacity))")
        print("内存大小: \(String(describing: configuration1.urlCache?.memoryCapacity))")
        print("沙盒大小: \(String(describing: configuration2.urlCache?.diskCapacity))")
        print("内存大小: \(String(describing: configuration2.urlCache?.memoryCapacity))")

• background创建一个可以在后台甚至app已经关闭的时候仍然在传输数据的会话。background模式可以在程序挂起，退出，崩溃的情况下运行task.也可以利用标识符来进行恢复。注意：后台session一定要在创建的时候赋予一个唯一的identifier,这样在app下次运行的时候，能够根据identifier来进行相关的区分，如果用户关闭了app,ios系统会关闭所有的background Session.而且被用户强制关闭了以后，iOS系统不回主动唤醒app,只有用户下次启动了app,数据传输才会继续

let configuration = URLSessionConfiguration.background(withIdentifier: self.createID())
let session = URLSession.init(configuration: configuration, delegate: self, delegateQueue: OperationQueue.main)        
session.downloadTask(with: url).resume()

session代理

extension ViewController:URLSessionDownloadDelegate{
    func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL) {
        // 下载完成 - 开始沙盒迁移
        print("下载完成 - \(location)")
        let locationPath = location.path
        //拷贝到用户目录（文件名以时间戳命名）
        let documnets = NSHomeDirectory() + "/Documents/" + self.lgCurrentDataTurnString() + ".mp4"
        print("移动地址:\(documnets)")
        //创建文件管理器
        let fileManager = FileManager.default
        try! fileManager.moveItem(atPath: locationPath, toPath: documnets)

    }
    
    func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didWriteData bytesWritten: Int64, totalBytesWritten: Int64, totalBytesExpectedToWrite: Int64) {
        print(" bytesWritten \(bytesWritten)\n totalBytesWritten \(totalBytesWritten)\n totalBytesExpectedToWrite \(totalBytesExpectedToWrite)")
        print("下载进度: \(Double(totalBytesWritten)/Double(totalBytesExpectedToWrite))\n")
    }
}

注意上面的设置还是不能达到后台下载，还需要设置下面2步

• 开启后台下载权限 (The completion handler to call when you finish processing the events. Calling this completion handler lets the system know that your app’s user interface is updated and a new snapshot can be taken.)

    用于保存后台下载的completionHandler
    var backgroundSessionCompletionHandler: (() -> Void)?
    
    func application(_ application: UIApplication, handleEventsForBackgroundURLSession identifier: String, completionHandler: @escaping () -> Void) {
        self.backgroundSessionCompletionHandler = completionHandler
    }

• 回调系统回调，告诉系统及时更新屏幕

func urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession) {
        print("后台任务下载回来")
        DispatchQueue.main.async {
            guard let appDelegate = UIApplication.shared.delegate as? AppDelegate, let backgroundHandle = appDelegate.backgroundSessionCompletionHandler else { return }
            backgroundHandle()
        }
    }

三、TCP的三次握手

• http请求是基于tcp连接的
• tcp有6种表示位
  1. SYN(synchronous建立联机)
  2. ACK(acknowledgement确认)
  3. PSH(push传送)
  4. FIN(finish结束)
  5. RST(reset重置)
  6. URG(urgent紧急)
• sequence number(顺序号码)
• acknowledge number(确认号码)
  

1. 客户端向服务器发出连接请求报文，这时报文首部中的同部位SYN=1,同时随机生成初始序列号seq=x,此时，TCP客户端进程进入了SYN-SENT(同步已发送状态)状态。TCP规定，SYN报文段(SYN=1的报文段)不能携带数据，但需要消耗掉一个序号。这个三次握手中的开始，表示客户端想要和服务端建立连接。
2. TCP服务器收到请求报文后，如果同意连接，则发出确认报文，确认报文中应该ACK=1,SYN=1,确认号是ack=x+1,同时也要自己随机初始化一个序列号seq=y,此时，TCP服务器进程进入了SYN-RCVD(同步收到)状态，这个报文也不能携带数据，但是同样要消耗一个序号。这个报文带有SYN(建立连接)和ACK(确认)标志，询问客户端是否准备好。
3. TCP客户进程收到确认后，还要向服务器给出确认。确认报文的ACK=1,ack=y+1,此时，TCP连接建立，客户端进入ESTABLISHED(已建立连接)状态，TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号，这里客户端表示我已经准备好。

• 为什么要三次握手呢
  • 举例：已失效的连接请求报文段
  • 客户端发送了第一个连接的请求报文，但由于网络不好，这个请求没有立即到达服务端，而是在某个网络节点中滞留了，直到某个时间才到达server，本来这已经是一个失效的报文，但是server端收到这个请求报文后，还是会像客户端发送确认的报文,表示同意连接。假如不采用三次握手，那么server发出确认后，新的建立就连接了，但其实这个请求是失效的请求，客户端是不会理睬server端的确认信息的，也不会像服务端发送确认的请求,但是server认为新的连接已经建立起来了，并一直等待客户端发来的数据，这样server端很多资源都白白浪费掉了，采用三次握手就是为了防止这种情况的发生，server会因为收不到确认的报文，就知道客户端并没有建立连接这就是三次握手的作用。

四、TCP数据的传输过程

• 建立连接后，两台主机就可以相互传输数据了。如下图所示：
  

• 主机A初始seq为1200,滑动窗体为100,向主机B传递数据的过程。

• 假设主机B在完全成功接收数据的基础上,那么主机B为了确认这一点，向主机A发送 ACK 包，并将 Ack 号设置为 1301。因此按如下的公式确认 Ack 号：
  Ack号 = Seq号 + 传递的字节数 + 1 （这是在完全接受成功的情况下）

• 主机A获得B传来的ack(1301)后,开始发送seq为1301,滑动窗体为100的数据。…

• 与三次握手协议相同，最后加 1 是为了告诉对方要传递的 Seq 号。上面说了，主机B完全成功接收A发来的数据才是这样的,如果存在丢包该如何

• 下面分析传输过程中数据包丢失的情况，如下图所示：
  

• 上图表示通过 Seq 1301 数据包向主机B传递100字节的数据，但中间发生了错误，主机B未收到。经过一段时间后，主机A仍未收到对于 Seq 1301 的ACK确认，因此尝试

• 重传数据。为了完成数据包的重传，TCP套接字每次发送数据包时都会启动定时器，如果在一定时间内没有收到目标机器传回的 ACK 包，那么定时器超时，数据包会重传。

五、TCP的四次挥手

1. TCP发送一个FIN(结束)，用来关闭客户端到服务端的连接
   • 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号+1)
   • 此时，客户端进入FIN-WAIT-1(终止等待1)的状态。TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务端收到这个FIN，他发回一个ACK(确认)，确认收到序号为收到序号+1，和SYN一样，一个FIN将占用一个序号。
   • 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器
   • 通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个
   • 状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
   • 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
3. 服务端发送一个FIN(结束)到客户端，服务端关闭客户端的连接。
   • 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，
   • 此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
4. 客户端发送ACK(确认)报文确认，并将确认的序号+1，这样关闭完成。
   • 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时
   • TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
   • 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

• 为什么是4次挥手呢？
  • 为了确保数据能够完成传输。
  • 关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也
  • 即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
  • 可能有人会有疑问，tcp我握手的时候为何ACK(确认)和SYN(建立连接)是一起发送。挥手的时候为什么是分开的时候发送呢.
  • 因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到
  • FIN报文时，很可能并不会立即关闭 SOCKET，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能
  • 发送FIN报文，因此不能一起发送。故需要四步握手。
• 客户端突然挂掉了怎么办？
  • 正常连接时，客户端突然挂掉了，如果没有措施处理这种情况，那么就会出现客户端和服务器端出现长时期的空闲。解决办法是在服务器端设置保活计时器，每当服务器收到
  • 客户端的消息，就将计时器复位。超时时间通常设置为2小时。若服务器超过2小时没收到客户的信息，他就发送探测报文段。若发送了10个探测报文段，每一个相隔75秒，
  • 还没有响应就认为客户端出了故障，因而终止该连接。