日常工作中，经常有人问到，接入S-CDN后网站访问变慢了、或者有时候不能访问、或者有499、50x等状态码等问题。
遇到这些问题的时候，用户会首先找到S-CDN厂商来排查问题，因为S-CDN一般都处在用户访问流量中的第一道，从表象上直接看首先会怀疑是S-CDN的问题。
一、问题在哪了？
问题具体出现在哪了？用户反馈的慢？那么时间都去哪了呢？经过多年的问题分析，从上图业务架构看，绝大部分问题出现在如下两个阶段，（本次主要来说在在数据流转发过程中连接建立、请求、响应等因素产生的时间问题，因跨运营商导致的慢的问题暂且不谈）。
1）客户端到S-CDN 阶段
2）S-CDN回源源站的阶段
二、连接建立阶段相关参数配置
2.1 实验：以Centos 7.7 SYN包丢弃重传为例
建立连接超时（7层和四层都存在），该现象会同时发生在 两个阶段注意：对于报文段2（服务端的SYN+ACK），同样会存在超时重传。对于建立连接时，SYN包丢失重传间隔2倍方递增。当重传达到最大次数后，即发生丢包.间隔为 1s+2s+4s+8s+16s+32s=63s。Windows（win7）上的实现，是只重传两次（即总共3次），间隔为3s,6s。即在01秒发第1包，则04秒发重传包，10秒重传包。（SYN重传时间间隔，注意该时间间隔是OS实现时自身确定的，而与网络的实际状况（畅通、拥塞）等无关）
2.2 centos6.2颇为奇怪（centos6.5 后按照 1，2，4，8 规则增加）\
设置tcp_syn_retries=4,syn 重传都是9s超时断开连接
三、7层ELB代理相关时间设置（以nginx 为例）
3.1 实验1：client_header_timeout 10
客户端在 10s 内没有发起HTTP 请求，既没有传输HTTP请求头
客户端在 10s 内发起了HTTP 请求，既没有传输完整的HTTP请求头，没有请求头结束标识，因此断开连接。
3.2 实验2： keepalive_timeout 10\
配置指定超时时间为10s，第一次HTTP请求后，10s内没有再次发起请求，断开连接。
配置指定超时时间为10s，第一次HTTP请求后，10s内再次发起请求，2次请求后，超时时间从第二次请求开始重新计算，2次请求后无HTTP请求，超时断开连接。
总结，业务访问慢的原因多且隐蔽，具体原因需要进行具体排查和分析，有时候业务访问慢从不同的业务状态码中也能看到端倪，具体状态码背后的秘密后续继续分析。
