一、linux核心引數
linux系統是通過proc檔案系統實現訪問核心內部資料結構及改變核心引數的，proc檔案系統是乙個偽檔案系統，通常掛載在/proc目錄下，可以通過改變/proc/sys目錄下檔案中的值對核心引數進行修改。
linux系統環境下，所有的裝置都被看作檔案來進行操作，建立的網路連線數同樣受限於作業系統的最大開啟檔案數。最大開啟檔案數會是系統記憶體的10%（以kb來計算），稱為系統級限制，可以使用sysctl -a | grep fs.file-max命令檢視系統級別的最大開啟檔案數。同時，核心為了不讓某個程序消耗掉所有的檔案資源，也會對單個程序最大開啟檔案數做預設值處理，稱之為使用者級限制，預設值一般是1024，使用ulimit -n命令可以檢視使用者級檔案描述符的最大開啟數。
nginx是一款web伺服器軟體，通過系統層面的網路優化可以提公升http資料傳輸的效率。http協議是基於tcp/ip通訊協議傳遞資料的，了解tcp建立連線（三次握手）及進行資料傳輸的機制是優化網路相關核心引數的基礎。
這裡對tcp三次握手四次揮手是一種狀態說一下我的理解。
三次揮手口述：首先主動開啟連線的客戶端結束closed階段，被動開啟的服務端也結束closed階段，進入到listen階段，隨後開始三次握手：
第一次握手：主動開始連線的客戶端向服務端傳送一段報文：
syn=1 這表示著想要和伺服器端建立連線，這個包名就叫syn包。
seq=x sequence number 序號，
隨之客戶端也進入syn_sent階段
第二次握手：服務端在接收到來自客戶端的報文之後，也給客戶端傳送一段報文：
ack=1 這表示接收到了客戶端的請求
syn=1這表示同意進行資料傳送
seq=y 服務端隨機生成的序號
這個資料報也叫作ack—fin包。
第三次握手：此時客戶端在收到了來自服務端的報文之後，已經確定此時服務端到客服端的資料傳輸沒有問題，但此時的服務端並不確認，所以還需要客戶端向伺服器傳送報文。
ack=1，表示確認接收到了服務端的資訊，此時資料資料傳輸是可靠的。
seq=x+1，
ack=y+1，將客戶端傳送來的seq=y加1作為自己的返回值。
此時客戶端和服務端都進入established，開始進行資料傳送。
四次揮手：
客戶端主動結束established階段，向伺服器端傳送報文：
seq=w，
fin=1，表示客戶端主動結束established階段。
隨後客戶端進入到fin_wait1階段
fin_wait階段，停止在客戶端往服務端的資料傳輸，但報文正常傳輸。
服務端在接受到客戶端傳送來的請求斷開連線的請求後，established階段結束，進入到了close_wait半關閉階段，服務端向客戶端回覆報文：
ack=1，表示接收到客戶端傳送來的資訊。
seq=v，多次傳送資料後到了這個數字。
ack=u+1，表示收到來自客戶端的資訊，並將客戶端傳送來的seq值＋1作為自己的返回值。
服務端已經接收到了來自客戶端斷開連線的申請，但是可能資料還沒有傳輸結束，所以還需要一次資料斷開的確認。此時客戶端也進入到了fin_wait2階段。
服務端向客戶端傳送報文：
fin=1，表示已經做好斷開資料連線準備。
ack=1,表示確認自己資料傳輸完成。
seq=w（多次傳輸結果後的seq數值。）
ack=u+1。
服務端進入到last_ack階段
客戶端接收到服務端傳送來的報文後，由fin_wait2階段進入到time_wait階段。
客戶端向伺服器傳送報文：
ack=1，表示確認接收到服務端資訊
ack=w+1，
seq=u+1，
服務端回歸closed階段。
客戶端等待完2msl之後，結束time-wait階段，進入closed階段，由此完成「四次揮手。
l syn_sent ：這個狀態與syn_rcvd 狀態相呼應，當客戶端socket執行connect()進行連線時，它首先傳送syn報文，然後隨即進入到syn_sent 狀態，並等待服務端的傳送三次握手中的第2個報文。syn_sent 狀態表示客戶端已傳送syn報文。
2.listen ：表示伺服器端的某個socket處於監聽狀態，可以接受客戶端的連線。
3.syn_rcvd ：表示伺服器接收到了來自客戶端請求連線的syn報文。在正常情況下，這個狀態是伺服器端的socket在建立tcp連線時的三次握手會話過程中的乙個中間狀態，很短暫，基本上用netstat很難看到這種狀態，除非故意寫乙個監測程式，將三次tcp握手過程中最後乙個ack報文不予傳送。當tcp連線處於此狀態時，再收到客戶端的ack報文，它就會進入到established 狀態。
4.established ：表示tcp連線已經成功建立。
5.fin_wait_1 ：這個狀態得好好解釋一下，其實fin_wait_1 和fin_wait_2 兩種狀態的真正含義都是表示等待對方的fin報文。而這兩種狀態的區別是：fin_wait_1狀態實際上是當socket在established狀態時，它想主動關閉連線，向對方傳送了fin報文，此時該socket進入到fin_wait_1 狀態。而當對方回應ack報文後，則進入到fin_wait_2 狀態。當然在實際的正常情況下，無論對方處於任何種情況下，都應該馬上回應ack報文，所以fin_wait_1 狀態一般是比較難見到的，而fin_wait_2 狀態有時仍可以用netstat看到。
6.fin_wait_2 ：上面已經解釋了這種狀態的由來，實際上fin_wait_2狀態下的socket表示半連線，即有一方呼叫close()主動要求關閉連線。注意：fin_wait_2 是沒有超時的（不像time_wait 狀態），這種狀態下如果對方不關閉（不配合完成4次揮手過程），那這個 fin_wait_2 狀態將一直保持到系統重啟，越來越多的fin_wait_2 狀態會導致核心crash。
7.time_wait ：表示收到了對方的fin報文，並傳送出了ack報文。 time_wait狀態下的tcp連線會等待2*msl（max segment lifetime，最大分段生存期，指乙個tcp報文在internet上的最長生存時間。每個具體的tcp協議實現都必須選擇乙個確定的msl值，rfc 1122建議是2分鐘，但bsd傳統實現採用了30秒，linux可以cat /proc/sys/net/ipv4/tcp_fin_timeout看到本機的這個值），然後即可回到closed 可用狀態了。如果fin_wait_1狀態下，收到了對方同時帶fin標誌和ack標誌的報文時，可以直接進入到time_wait狀態，而無須經過fin_wait_2狀態。（這種情況應該就是四次揮手變成三次揮手的那種情況）
closing ：這種狀態在實際情況中應該很少見，屬於一種比較罕見的例外狀態。正常情況下，當一方傳送fin報文後，按理來說是應該先收到（或同時收到）對方的ack報文，再收到對方的fin報文。但是closing 狀態表示一方傳送fin報文後，並沒有收到對方的ack報文，反而卻也收到了對方的fin報文。什麼情況下會出現此種情況呢？那就是當雙方幾乎在同時close()乙個socket的話，就出現了雙方同時傳送fin報文的情況，這是就會出現closing 狀態，表示雙方都正在關閉socket連線。
close_wait ：表示正在等待關閉。怎麼理解呢？當對方close()乙個socket後傳送fin報文給自己，你的系統毫無疑問地將會回應乙個ack報文給對方，此時tcp連線則進入到close_wait狀態。接下來呢，你需要檢查自己是否還有資料要傳送給對方，如果沒有的話，那你也就可以close()這個socket並傳送fin報文給對方，即關閉自己到對方這個方向的連線。有資料的話則看程式的策略，繼續傳送或丟棄。簡單地說，當你處於close_wait 狀態下，需要完成的事情是等待你去關閉連線。
last_ack ：當被動關閉的一方在傳送fin報文後，等待對方的ack報文的時候，就處於last_ack 狀態。當收到對方的ack報文後，也就可以進入到closed 可用狀態了。
closed：初始狀態，表示tcp連線是「關閉著的」或「未開啟的」。
以上。
nginx 學習筆記 2
7.日誌分割 需要定時任務shell bin bash logs path var logs mkdir p date d yesterday y date d yesterday m mv access.log date d yesterday y date d yesterday m acces...
Docker學習筆記 2 執行nginx
這裡我們使用網易蜂巢來查詢相應的映象 然後就就執行這個映象 docker run hub.c.163.com library nginx執行後發現結果是一片空白，這是為啥呢?因為這樣執行我們只是在前台進行執行而不是後台，而nginx執行方式最好是在後台執行，所以加上 d這個引數，代表run in b...
nginx 學習筆記 2 nginx新手入門
這篇手冊簡單介紹了nginx，並提供了一些可以操作的簡單的工作。前提是nginx已經被安裝到你的伺服器上。如果沒有安裝，請閱讀上篇 nginx 學習筆記 1 nginx安裝。這篇手冊主要內容 1.如何啟動和停止nginx，如何載入nginx配置 2.配置檔案的結構 3.如何安裝nginx來做靜態內容...