目錄
1.HTTP1.0和HTTP1.1區別
2.socket系列接口與TCP協議
3.傳輸長數據的時候考慮網絡問題
4.慢查詢如何優化
5.C++的垃圾回收機制
1.HTTP1.0和HTTP1.1區別
- 在連接方式上，HTTP1.0默認采用的是短鏈接的方式，就建立一次通信，也就是說即使在TCP協議下，完成了一個HTTP報文的請求和響應之后，也會關閉連接。這種頻繁的建立和關閉連接會增加服務器的負擔。雖然說HTTP1.0版本不支持長連接，但是可以通過設置Connection: Keep-Alive字段來啟動類似長連接的功能，但是是不標準的方式。而HTTP1.1引入了長連接機制，在一個TCP連接上可以傳遞多個HTTP請求與響應報文。
- 緩存機制上，HTTP1.0采用的是通過字段的方式指定緩存的內容有效時間，客戶端在這段時間內可以使用緩存的副本而無需向服務器重新請求。但是這樣的話也無法驗證數據的實時性，可能服務端更新了呢？而HTTP1.1版本的話，增加了緩存控制能力，提供了字段來規定客戶端在使用緩存內容的時候，需要先向服務端驗證數據的有效性。
2.socket系列接口與TCP協議
- socket建立網絡通信套接字、bind進行ip地址和端口號綁定、服務端進行listen監聽操作是在通信之間進行的。
- connect接口：操作客戶端向服務器發起連接請求，在TCP協議層的操作就是相當于發起三次握手，直到客戶端收到第二次握手的SYN+ACK響應報文，connect函數才會返回，期間會一直阻塞住。
- accept接口：服務端在接收到第三次握手的ACK報文之后，會和客戶端真正的建立連接，之后accept就是將全連接隊列中的連接對象與文件描述符建立連接。
- listen接口的第二個參數：就是全連接隊列的最大長度。
3.傳輸長數據的時候考慮網絡問題
? ? ? ? 當網絡出現問題的時候導致的數據丟包的問題，并非是TCP協議能夠解決的問題了，因為TCP協議是在網絡通暢，雙方連接沒有斷開的情況下，維護發送但沒有收到應答的時候，但是一旦網絡出問題了，就相當于連接斷開了，那么在銷毀這個連接的時候，TCP緩存的數據也就跟著銷毀了。但是我們想做到的是，當網絡出現問題之后，在重新建立連接，數據會從上一次斷開連接的位置之后發送數據。
????????那么首先就需要在應用層協議的報頭上加入類似于TCP協議的32位序號和確認序號了，但是這里一個負責發送一個負責響應，所以只用一個序號就可以了。服務端報文的序號代表發送的數據序號，客戶端報文的序號代表接收到的數據塊序號。
? ? ? ? 之后再服務端的應用層，維護一個指針指向整體數據的已經發送并且得到確認的位置，那么就分成了兩個區域，指針左邊就是已發送已確認區域，右邊是沒發送或者發送了沒有確認的區域，這樣的話，該指針指向的位置，就是客戶端收到數據的位置。如果說網絡出現問題的話，再重新連接之后，會根據客戶端發來的序號，更新指針的位置，繼續發送數據。
? ? ? ? 對于客戶端來說，也需要再應用層將這些數據保存起來，并記錄收到的最后一個數據的序號，在網絡問題斷開連接后，重新連接，會將該序號放進報頭中，告訴服務端該從哪里發送了。
? ? ? ? 因為是分塊發送的，所以服務端最后需要告訴客戶端數據發送完畢了，所以就會出現很多類型報文，所以還需要再報頭添加報文類型字段：客戶端請求響應報文，服務端發送數據塊報文、客戶端接收到數據塊的響應報文、服務端發送完所有數據的報文。
????????
4.慢查詢如何優化
? ? ? ? 慢查詢是數據庫的一個概念，指的是執行時間過長超過了long_query_time設定的值的擦汗尋語句，就屬于慢查詢語句。慢查詢會對數據庫的性能產生嚴重影響，當數據庫中有大量的慢查詢的時候，會導致數據庫服務器的CPU使用了過高。還可能導致數據庫連接池被沾滿，新的請求無法及時獲取到。
- 優化查詢語句本身：第一：索引優化；第二：子查詢優化，盡量減少嵌套查詢的使用，例如，有一個查詢需要獲取購買了某一商品的用戶信息，一種不好的做法是先通過子查詢找到購買了該商品的用戶 ID，然后再在另一個查詢中根據這些用戶 ID 獲取用戶信息。這種嵌套子查詢可以通過使用連接（JOIN）操作來優化；第三：盡量不要使用select *語句。
- 優化數據庫架構：第一：采用合理的數據類型定義字段；第二：對于大型數據表，可以考慮使用分區結構
- 優化服務器配置：第一：調整緩存大小，第二：硬件的升級
5.C++的垃圾回收機制
? ? ? ? C++沒有配套的垃圾回收機制，需要程序員使用new、delete去手動的管理內存資源，也可以使用C++11的智能指針，配合析構函數來實現對資源的自動管理。或者使用第三方庫來實現資源的回收工作。
