Alamofire初探一. Alamofire概述二. URLSesstion基础三、TCP的三次握手四、TCP数据的传输过程五、TCP的四次挥手一. 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()此过程省略了一个重要的东西URLSessionConfigurationopen class var default: URLSessionConfiguration { get } open class var ephemeral: URLSessionConfiguration { get } available(iOS 8.0, *) open class func background(withIdentifier identifier: String) - URLSessionConfigurationURLSessionConfiguration有三种模式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种表示位SYN(synchronous建立联机)ACK(acknowledgement确认)PSH(push传送)FIN(finish结束)RST(reset重置)URG(urgent紧急)sequence number(顺序号码)acknowledge number(确认号码)客户端向服务器发出连接请求报文这时报文首部中的同部位SYN1,同时随机生成初始序列号seqx,此时TCP客户端进程进入了SYN-SENT(同步已发送状态)状态。TCP规定SYN报文段(SYN1的报文段)不能携带数据但需要消耗掉一个序号。这个三次握手中的开始表示客户端想要和服务端建立连接。TCP服务器收到请求报文后如果同意连接则发出确认报文确认报文中应该ACK1,SYN1,确认号是ackx1,同时也要自己随机初始化一个序列号seqy,此时TCP服务器进程进入了SYN-RCVD(同步收到)状态这个报文也不能携带数据但是同样要消耗一个序号。这个报文带有SYN(建立连接)和ACK(确认)标志询问客户端是否准备好。TCP客户进程收到确认后还要向服务器给出确认。确认报文的ACK1,acky1,此时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的四次挥手TCP发送一个FIN(结束)用来关闭客户端到服务端的连接客户端进程发出连接释放报文并且停止发送数据。释放数据报文首部FIN1,其序列号为sequ(等于前面已经传送过来的数据的最后一个字节的序号1)此时客户端进入FIN-WAIT-1(终止等待1)的状态。TCP规定FIN报文段即使不携带数据也要消耗一个序号。服务端收到这个FIN他发回一个ACK(确认)确认收到序号为收到序号1和SYN一样一个FIN将占用一个序号。服务器收到连接释放报文发出确认报文ACK1acku1并且带上自己的序列号seqv此时服务端就进入了CLOSE-WAIT关闭等待状态。TCP服务器通知高层的应用进程客户端向服务器的方向就释放了这时候处于半关闭状态即客户端已经没有数据要发送了但是服务器若发送数据客户端依然要接受。这个状态还要持续一段时间也就是整个CLOSE-WAIT状态持续的时间。客户端收到服务器的确认请求后此时客户端就进入FIN-WAIT-2终止等待2状态等待服务器发送连接释放报文在这之前还需要接受服务器发送的最后的数据。服务端发送一个FIN(结束)到客户端服务端关闭客户端的连接。服务器将最后的数据发送完毕后就向客户端发送连接释放报文FIN1acku1由于在半关闭状态服务器很可能又发送了一些数据假定此时的序列号为seqw此时服务器就进入了LAST-ACK最后确认状态等待客户端的确认。客户端发送ACK(确认)报文确认并将确认的序号1这样关闭完成。客户端收到服务器的连接释放报文后必须发出确认ACK1ackw1而自己的序列号是sequ1此时客户端就进入了TIME-WAIT时间等待状态。注意此时TCP连接还没有释放必须经过2∗∗MSL最长报文段寿命的时间后当客户端撤销相应的TCB后才进入CLOSED状态。服务器只要收到了客户端发出的确认立即进入CLOSED状态。同样撤销TCB后就结束了这次的TCP连接。可以看到服务器结束TCP连接的时间要比客户端早一些。为什么是4次挥手呢为了确保数据能够完成传输。关闭连接时当收到对方的FIN报文通知时它仅仅表示对方没有数据发送给你了但未必你所有的数据都全部发送给对方了所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后再发送FIN报文给对方来表示你同意现在可以关闭连接了所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。可能有人会有疑问tcp我握手的时候为何ACK(确认)和SYN(建立连接)是一起发送。挥手的时候为什么是分开的时候发送呢.因为当Server端收到Client端的SYN连接请求报文后可以直接发送SYNACK报文。其中ACK报文是用来应答的SYN报文是用来同步的。但是关闭连接时当Server端收到FIN报文时很可能并不会立即关闭 SOCKET所以只能先回复一个ACK报文告诉Client端“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了我才能发送FIN报文因此不能一起发送。故需要四步握手。客户端突然挂掉了怎么办正常连接时客户端突然挂掉了如果没有措施处理这种情况那么就会出现客户端和服务器端出现长时期的空闲。解决办法是在服务器端设置保活计时器每当服务器收到客户端的消息就将计时器复位。超时时间通常设置为2小时。若服务器超过2小时没收到客户的信息他就发送探测报文段。若发送了10个探测报文段每一个相隔75秒还没有响应就认为客户端出了故障因而终止该连接。
