Ⅰ iphone6允許運營商網路緩存開關在哪
允許運營商網路緩存開關不是在蘋果自帶的設置中設置的，是在某個軟體的設置中設置的，比如騰訊視頻，或者任意一個你想要設置的APP里進行設置。
Ⅱ 網路通信
我們要理解網路中進程如何通信，得解決兩個問題：
a、我們要如何標識一台主機，即怎樣確定我們將要通信的進程是在那一台主機上運行。
b、我們要如何標識唯一進程，本地通過pid標識，網路中應該怎樣標識？
解決辦法：
a、TCP/IP協議族已經幫我們解決了這個問題，網路層的「ip地址」可以唯一標識網路中的主機
b、傳輸層的「協議+埠」可以唯一標識主機中的應用程序（進程），因此，我們利用三元組（ip地址，協議，埠）就可以標識網路的進程了，網路中的進程通信就可以利用這個標志與其它進程進行交互
以UDP傳輸為例：
1、物理層：
解決兩個硬體之間怎麼通信的問題，常見的物理媒介有光纖、電纜、中繼器等。它主要定義物理設備標准，如網線的介面類型、光纖的介面類型、各種傳輸介質的傳輸速率等。
它的主要作用是傳輸比特流（就是由1、0轉化為電流強弱來進行傳輸，到達目的地後在轉化為1、0，也就是我們常說的數模轉換與模數轉換）。這一層的數據叫做比特。
2、數據鏈路層：
在計算機網路中由於各種干擾的存在，物理鏈路是不可靠的。該層的主要功能就是：通過各種控制協議，將有差錯的物理信道變為無差錯的、能可靠傳輸數據幀的數據鏈路。
它的具體工作是接收來自物理層的位流形式的數據，並封裝成幀，傳送到上一層；同樣，也將來自上層的數據幀，拆裝為位流形式的數據轉發到物理層。這一層的數據叫做幀。
3、網路層：
計算機網路中如果有多台計算機，怎麼找到要發的那台？如果中間有多個節點，怎麼選擇路徑？這就是路由要做的事。
該層的主要任務就是：通過路由選擇演算法，為報文（該層的數據單位，由上一層數據打包而來）通過通信子網選擇最適當的路徑。這一層定義的是IP地址，通過IP地址定址，所以產生了IP協議。
4、傳輸層：
當發送大量數據時，很可能會出現丟包的情況，另一台電腦要告訴是否完整接收到全部的包。如果缺了，就告訴丟了哪些包，然後再發一次，直至全部接收為止。
簡單來說，傳輸層的主要功能就是：監控數據傳輸服務的質量，保證報文的正確傳輸。
5、會話層：
雖然已經可以實現給正確的計算機，發送正確的封裝過後的信息了。但我們總不可能每次都要調用傳輸層協議去打包，然後再調用IP協議去找路由，所以我們要建立一個自動收發包，自動定址的功能。於是會話層出現了：它的作用就是建立和管理應用程序之間的通信。
6、表示層：
表示層負責數據格式的轉換，將應用處理的信息轉換為適合網路傳輸的格式，或者將來自下一層的數據轉換為上層能處理的格式。
7、應用層：
應用層是計算機用戶，以及各種應用程序和網路之間的介面，其功能是直接向用戶提供服務，完成用戶希望在網路上完成的各種工作。前端同學對應用層肯定是最熟悉的。
應用層（應用，表示，會話）：TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet 等等
傳輸層：TCP，UDP
網路層：IP，ICMP，OSPF，EIGRP，IGMP
數據鏈路層：SLIP，CSLIP，PPP，MTU
重要的 協議族介紹:
IP 定義了 TCP/IP 的地址,定址方法,以及路由規則。現在廣泛使用的 IP 協議有 IPv4 和 IPv6 兩種:IPv4 使用 32 位二進制整數做地址,一般使用點分十進制方式表示,比如 192.168.0.1。
IP 地址由兩部分組成,即網路號和主機號。故一個完整的 IPv4 地址往往表示 為 192.168.0.1/24 或192.168.0.1/255.255.255.0 這種形式。
IPv6 是為了解決 IPv4 地址耗盡和其它一些問題而研發的最新版本的 IP。使用 128 位 整數表示地址,通常使用冒號分隔的十六進制來表示,並且可以省略其中一串連續的 0,如:fe80::200:1ff:fe00:1。
目前使用並不多！
http協議對應於應用層，tcp協議對應於傳輸層，ip協議對應於網路層。
TPC/IP【TCP（傳輸控制協議）和IP（網際協議）】，主要解決數據如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。關於TCP/IP和HTTP協議的關系，網路有一段比較容易理解的介紹：「我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝HTTP 文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。」
術語TCP/IP代表傳輸控制協議/網際協議，指的是一系列協議。「IP」代表網際協議，TCP和UDP使用該協議從一個網路傳送數據包到另一個網路。把IP想像成一種高速公路，它允許其它協議在上面行駛並找到到其它電腦的出口。TCP和UDP是高速公路上的「卡車」，它們攜帶的貨物就是像HTTP，文件傳輸協議FTP這樣的協議等。
你應該能理解，TCP和UDP是FTP，HTTP和SMTP之類使用的傳輸層協議。雖然TCP和UDP都是用來傳輸其他協議的，它們卻有一個顯著的不同：TCP提供有保證的數據傳輸，而UDP不提供。這意味著TCP有一個特殊的機制來確保數據安全的不出錯的從一個端點傳到另一個端點，而UDP不提供任何這樣的保證。
URL的全稱是Uniform Resource Locator（統一資源定位符）
通過1個URL，能找到互聯網上唯一的1個資源。
URL就是資源的地址、位置，互聯網上的每個資源都有一個唯一的URL。
URL的基本格式 =協議://主機地址/路徑
協議：不同的協議，代表著不同的資源查找方式、資源傳輸方式
主機地址：存放資源的主機（伺服器）的IP地址（域名）
資源在主機（伺服器）中的具體位置
1、HTTP協議的幾個重要概念
1.連接(Connection)：一個傳輸層的實際環流，它是建立在兩個相互通訊的應用程序之間。
2.消息(Message)：HTTP通訊的基本單位，包括一個結構化的八元組序列並通過連接傳輸。
3.請求(Request)：一個從客戶端到伺服器的請求信息包括應用於資源的方法、資源的標識符和協議的版本號
4.響應(Response)：一個從伺服器返回的信息包括HTTP協議的版本號、請求的狀態(例如「成功」或「沒找到」)和文檔的MIME類型。
5.資源(Resource)：由URI標識的網路數據對象或服務。
6.實體(Entity)：數據資源或來自服務資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應信息中。一個實體包括實體頭信息和實體的本身內容。
7.客戶機(Client)：一個為發送請求目的而建立連接的應用程序。
8.用戶代理(Useragent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。
9.伺服器(Server)：一個接受連接並對請求返回信息的應用程序。
10.源伺服器(Originserver)：是一個給定資源可以在其上駐留或被創建的伺服器。
11.代理(Proxy)：一個中間程序，它可以充當一個伺服器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內部或經過傳遞到其它的伺服器中。一個代理在發送請求信息之前，必須解釋並且如果可能重寫它。
代理經常作為通過防火牆的客戶機端的門戶，代理還可以作為一個幫助應用來通過協議處理沒有被用戶代理完成的請求。
12.網關(Gateway)：一個作為其它伺服器中間媒介的伺服器。與代理不同的是，網關接受請求就好象對被請求的資源來說它就是源伺服器；發出請求的客戶機並沒有意識到它在同網關打交道。
網關經常作為通過防火牆的伺服器端的門戶，網關還可以作為一個協議翻譯器以便存取那些存儲在非HTTP系統中的資源。
13.通道(Tunnel)：是作為兩個連接中繼的中介程序。一旦激活，通道便被認為不屬於HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經常使用。
14.緩存(Cache)：反應信息的局域存儲。
TCP(Transmission Control Protocol) 傳輸控制協議。TCP是主機對主機層的傳輸控制協議，提供可靠的連接服務，採用三次握確認建立一個連接。位碼即tcp標志位，有6種 標示:SYN(synchronous建立聯機) ACK(acknowledgement 確認) PSH(push傳送) FIN(finish結束) RST(reset重置) URG(urgent緊急)Sequence number(順序號碼) Acknowledge number(確認號碼)。
手機能夠使用聯網功能是因為手機底層實現了TCP/IP協議，可以使手機終端通過無線網路建立TCP連接。TCP協議可以對上層網路提供介面，使上層網路數據的傳輸建立在「無差別」的網路之上。建立起一個TCP連接需要經過「三次握手」：
第一次握手：客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。握手完成後，兩台主機開始傳輸數據了。
為什麼要三次握手？
如果只有一次握手，Client不能確定與Server的單向連接，更加不能確定Server與Client的單向連接；
如果只有兩次握手，Client確定與Server的單向連接，但是Server不能確定與Client的單向連接；
只有三次握手，Client與Server才能相互確認雙向連接，實現雙工數據傳輸。
握手過程中傳送的包里不包含數據，三次握手完畢後，客戶端與伺服器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉連接之前，TCP 連接都將被一直保持下去。斷開連接時伺服器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過「四次揮手」。
第一次揮手：
Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。
第二次揮手：
Server收到FIN後，發送一個ACK給Client，確認序號為收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。
第三次揮手：
Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。
第四次揮手：
Client收到FIN後，Client進入TIME_WAIT狀態，接著發送一個ACK給Server，確認序號為收到序號+1，Server進入CLOSED狀態，完成四次揮手。
為什麼要四次揮手？
「三次握手」的第二次握手發送SYN+ACK回應第一次握手的SYN，但是「四次揮手」的第二次揮手只能發送ACK回應第一次揮手的FIN，因為此時Server可能還有數據傳輸給Client，所以Server傳輸數據完成後才能發起第三次揮手發送FIN給Client，等待Client的第四次揮手ACK。
http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議。HTTPS其實是有兩部分組成：HTTP +SSL/ TLS，也就是在HTTP上又加了一層處理加密信息的模塊。採用HTTPS協議的伺服器必須要有一套數字證書，可以自己製作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。SSL介於應用層和TCP層之間。應用層數據不再直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用層收到的數據進行加密，並增加自己的SSL頭。
1.怎麼解決tcp拆包和黏包的問題
粘包、拆包發生原因
發生TCP粘包或拆包有很多原因，現列出常見的幾點，可能不全面，歡迎補充，
1、要發送的數據大於TCP發送緩沖區剩餘空間大小，將會發生拆包。
2、待發送數據大於MSS（最大報文長度），TCP在傳輸前將進行拆包。
3、要發送的數據小於TCP發送緩沖區的大小，TCP將多次寫入緩沖區的數據一次發送出去，將會發生粘包。
4、接收數據端的應用層沒有及時讀取接收緩沖區中的數據，將發生粘包。
等等。
粘包、拆包解決辦法
解決問題的關鍵在於如何給每個數據包添加邊界信息，常用的方法有如下幾個：
1、發送端給每個數據包添加包首部，首部中應該至少包含數據包的長度，這樣接收端在接收到數據後，通過讀取包首部的長度欄位，便知道每一個數據包的實際長度了。
2、發送端將每個數據包封裝為固定長度（不夠的可以通過補0填充），這樣接收端每次從接收緩沖區中讀取固定長度的數據就自然而然的把每個數據包拆分開來。
3、可以在數據包之間設置邊界，如添加特殊符號，這樣，接收端通過這個邊界就可以將不同的數據包拆分開。
等等。
2.upd丟包
1、接收端處理時間過長導致丟包：調用recv方法接收端收到數據後，處理數據花了一些時間，處理完後再次調用recv方法，在這二次調用間隔里,發過來的包可能丟失。對於這種情況可以修改接收端，將包接收後存入一個緩沖區，然後迅速返回繼續recv。
2、發送的包巨大丟包：雖然send方法會幫你做大包切割成小包發送的事情，但包太大也不行。例如超過50K的一個udp包，不切割直接通過send方法發送也會導致這個包丟失。這種情況需要切割成小包再逐個send。
3、發送的包較大，超過接受者緩存導致丟包：包超過mtu size數倍，幾個大的udp包可能會超過接收者的緩沖，導致丟包。這種情況可以設置socket接收緩沖。以前遇到過這種問題，我把接收緩沖設置成64K就解決了。
int nRecvBuf=32*1024;//設置為32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
4、發送的包頻率太快：雖然每個包的大小都小於mtu size 但是頻率太快，例如40多個mut size的包連續發送中間不sleep，也有可能導致丟包。這種情況也有時可以通過設置socket接收緩沖解決，但有時解決不了。所以在發送頻率過快的時候還是考慮sleep一下吧。
5、區域網內不丟包，公網上丟包。這個問題我也是通過切割小包並sleep發送解決的。如果流量太大，這個辦法也不靈了。總之udp丟包總是會有的，如果出現了用我的方法解決不了，還有這個幾個方法： 要麼減小流量，要麼換tcp協議傳輸，要麼做丟包重傳的工作。
一個是客戶端發送過快，網路狀況不好或者超過伺服器接收速度，就會丟包。
第二個原因是伺服器收到包後，還要進行一些處理，而這段時間客戶端發送的包沒有去收，造成丟包。
那麼需要做的是
客戶端降低發送速度，可以等待回包，或者加一些延遲。伺服器部分單獨開一個線程，去接收UDP數據，存放在一個緩沖區中，又另外的線程去處理收到的數據，盡量減少因為處理數據延時造成的丟包。
有兩種方法解決UDP 丟包的問題：
方法一：重新設計一下協議，增加接收確認超時重發。（推薦）
方法二：在接收方，將通信和處理分開，增加個應用緩沖區；如果有需要增加接收socket的系統緩沖區。（本方法不能從根本解決問題，只能改善）
https://jiahao..com/s?id=1654225744653405133&wfr=spider&for=pc
https://www.jianshu.com/p/066d99da7cbd
https://jiahao..com/s?id=1654225744653405133&wfr=spider&for=pc
https://blog.csdn.net/qq_31337311/article/details/80781273
https://www.cnblogs.com/jiangzhaowei/p/8996810.html
http://blog.sina.com.cn/s/blog_d2bb5eff0102wbq2.html