iOS Swift URLSession POST 请求因慢速 API 调用而重复

Question

我有一个下载任务，首先调用一个 REST API，服务器需要为其生成一个相当大的文件，该文件需要几分钟才能生成，因为它是 CPU 和磁盘 IO 密集型的。客户端等待服务器使用它生成的文件的 URL 给出 JSON 响应。在获得第一个结果后开始文件下载。

对于生成特别大文件的调用，这会导致服务器响应速度非常慢，我看到我的代码未启动的重复请求。

最初在服务器端工作的人告诉我重复请求。然后我设置了一种检查网络流量的方法。这是通过设置连接到有线网络的 Mac 并启用网络共享并使用 Proxyman 检查从 iPhone 到 API 服务器的流量来完成的。我在网络层看到同一 API 请求的多个实例，但我的代码从未收到通知。

代码如下所示

@objc class OfflineMapDownloadManager : NSObject, URLSessionDelegate, URLSessionDownloadDelegate {
@objc func download(){     
    
    let config = URLSessionConfiguration.background(withIdentifier: "OfflineMapDownloadSession")
    config.timeoutIntervalForRequest = 500
    config.shouldUseExtendedBackgroundIdleMode = true
    config.sessionSendsLaunchEvents = true
  
    urlSession = URLSession(configuration: config, delegate: self, delegateQueue: nil)    
    getMapUrlsFromServer(bounds)
}


func getMapUrlsFromServer(){
    
    var urlString = "http://www.fake.com/DoMakeMap.php" 
    if let url = URL(string: urlString) {
        let request = NSMutableURLRequest(url: url)
        //...Real code sets up a JSON body in to params...
        request.httpBody = params.data(using: .utf8 )
        request.setValue("application/json", forHTTPHeaderField: "Content-Type")
        request.httpMethod = "POST"
        request.timeoutInterval = 500
        urlSession?.configuration.timeoutIntervalForRequest = 500
        urlSession?.configuration.timeoutIntervalForResource = 500
        request.httpShouldUsePipelining = true
        let backgroundTask = urlSession?.downloadTask(with: request as URLRequest)
        backgroundTask?.countOfBytesClientExpectsToSend = Int64(params.lengthOfBytes(using: .utf8))
        backgroundTask?.countOfBytesClientExpectsToReceive = 1000
        backgroundTask?.taskDescription = "Map Url Download"
        backgroundTask?.resume()
    }
}

func urlSession(_ session: URLSession, downloadTask: URLSessionDownloadTask, didFinishDownloadingTo location: URL) {    
    if (downloadTask.taskDescription == "CTM1 Url Download") {
        do {
            let data = try Data(contentsOf: location, options: .mappedIfSafe)
            let jsonResult = try JSONSerialization.jsonObject(with: data, options: .mutableLeaves)
            if let jsonResult = jsonResult as? Dictionary<String, AnyObject> {
                if let ctm1Url = jsonResult["CTM1Url"] as? String {
                    if let filesize = jsonResult["filesize"] as? Int {
                        currentDownload?.ctm1Url = URL(string: ctm1Url)
                        currentDownload?.ctm1FileSize = Int32(filesize)
                        if (Int32(filesize) == 0) {
                            postDownloadFailed()
                        } else {
                            startCtm1FileDownload(ctm1Url,filesize)
                        }
                    }
                }
            }
        } catch {
            postDownloadFailed()
        }
    }
}    

这个下载类还有更多内容，因为它会在第一次 api 调用完成后下载实际文件。由于问题发生在该代码执行之前，因此我没有将其包含在示例代码中。

Proxyman 的日志显示 API 调用在（分：秒）46:06、47:13、48:21、49:30、50:44、52:06、53:45 发出 看起来请求会以刚刚超过 1 分钟的间隔重复。

有一个 API 字段，我可以在其中输入任何值，服务器会将其回显给我。我在那里放置了一个用 CACurrentMediaTime() 生成的时间戳，并登录 Proxyman 显示它确实是相同的 API 调用，所以我的代码不可能被多次调用。似乎 iOS 网络层正在重新发出 http 请求，因为服务器需要很长时间才能响应。这最终会导致服务器出现问题并且 API 失败。

任何帮助将不胜感激。

Answer 1

我认为问题在于使用 URLSessionConfiguration.background(withIdentifier:) 进行此 api 调用。

使用此方法初始化适合在应用程序在后台运行时传输数据文件的配置对象。 使用此对象配置的会话将传输控制权移交给系统，系统在单独的进程中处理传输。在 iOS 中，即使应用程序本身处于运行状态，此配置也可以继续传输暂停或终止。

所以问题在于，由于 API 使用错误，系统正在不必要地重试您的请求。

这是我的推荐 -

1. 使用默认会话配置（非后台）。
2. 执行这个 api 调用来启动这个漫长的工作，不要让客户端等待这个工作，一旦这个工作启动，服务器端就会返回一个 job_id 给客户端。
3. 客户端现在可以使用该 job_id 值每 X 秒轮询一次服务器以了解作业的状态，甚至可以在需要时在客户端显示进度。
4. 作业完成后，客户端下次轮询时，会获取此大文件的下载 URL。
5. 下载文件（根据需要使用默认/后台会话配置）。

Answer 2

这听起来很像 TCP 重传。如果客户端发送一个 TCP 段，而服务器在很短的时间内没有确认收到，则客户端假定该段没有到达目的地，并再次发送该段。这是一个比 URLSession 低得多的机制。

此 API 正在使用的 HTTP 服务器应用程序（想想 Apache、IIS、LigHTTPd、nginx 等）可能被配置为使用响应数据进行确认，以节省打包和帧开销。如果是这样，并且如果响应数据花费的时间比客户端的 TCP 重传超时时间长，就会出现这种行为。

你有连接的数据包捕获吗？如果没有，请尝试使用 tcpdump 收集一份并在 Wireshark 中查看。如果我是对的，您会看到多个请求，并且它们都将具有相同的序列号。

至于如果这是问题如何解决，我不确定。服务器应该在收到请求后立即确认。