mac (和很多unix一樣) 自帶ftp客戶端: /usr/bin/ftp

連接上后大概會使用 mput 等命令

git pull 了解一下

好吧，這個問題我自己來回答啦。

在linux系統(tǒng)上，使用tcpdump抓包結(jié)束之后會提示：

簡單來說， captured是tcpdump處理過之后，得到的數(shù)據(jù)包數(shù)量，亦即最終獲得的pcap文件中數(shù)據(jù)包數(shù)量； received是經(jīng)過過濾器處理的所有數(shù)據(jù)包； dropped則是未經(jīng)處理的數(shù)據(jù)包數(shù)量。
received by filter的結(jié)果這取決于運(yùn)行tcpdump的操作系統(tǒng)及其配置。如果指定一個過濾器,包無論是否被篩選器表達(dá)式匹配，即使他們被篩選器表達(dá)式匹配，無論tcpdump是否讀取和處理他們，都會進(jìn)行計算，即收到一個包，received by filter會加1。如果sock的接收buffer被填滿時，則把這個數(shù)據(jù)包丟棄，將dropped by kernel加1，所以 received by filter和dropped by kernel的計數(shù)由內(nèi)核維護(hù)。
造成丟包的原因，是由于libcap抓到包后，tcpdump上層沒有及時的取出，導(dǎo)致libcap緩沖區(qū)溢出，從而丟棄了未處理包，此處即顯示為dropped by kernel。這里的kernel并不是說是被linux內(nèi)核拋棄的，而是被tcpdump的內(nèi)核，即libcap拋棄掉的。

解決辦法也有一些，比如：
1、-n 參數(shù)，禁止反向域名解析（）
2、-s 參數(shù)，控制抓取數(shù)據(jù)包的長度
（采用更大的捕捉范圍既增加了處理報文的時間,又相應(yīng)的減少了報文的緩沖數(shù)量,可能導(dǎo)致報文的丟失。嘗試把snaplen設(shè)的盡量小,只要能夠容納需要的協(xié)議信息就可以。）
3、將數(shù)據(jù)包輸出到cap文件
4、用sysctl修改SO_REVBUF參數(shù)，增加libcap緩沖區(qū)長度

方法1我試過了，效果不理想。
方法2也試過了，效果不錯。但我本來就是要測抓包性能的，肯定得把包抓全啊，想想之后放棄了這個方案。
方法3這個.....我本來就是輸出到文件里的，但還是有丟包的問題，所以好像并沒有什么卵用。
方法4感覺有點(diǎn)復(fù)雜，不過前面解釋里也提到是因?yàn)榫彌_區(qū)不夠才導(dǎo)致的丟包，遂覺得這方法有門，不過就是麻煩了一點(diǎn)。然后靈機(jī)一動，我查到了tcpdump里有個-B參數(shù)可以修改緩沖區(qū)大小，哈哈??！

所以最后的解決辦法就是：我使用-B參數(shù)修改了tcpdump的緩沖區(qū)大小?。?！
這里要注意的是如果未指定 -B 選項(xiàng)，那么緩沖區(qū)大小缺省為32768，既然這樣我就乘二試了試，-B 65535。
嘻嘻，一下子什么丟包都飛走了~~

@羊德超 可否部分mock部分走真實(shí)的？

Linux的管道實(shí)現(xiàn)是個環(huán)形緩沖區(qū)：

/**
 *    struct pipe_buffer - a linux kernel pipe buffer
 *    @page: the page containing the data for the pipe buffer
 *    @offset: offset of data inside the @page
 *    @len: length of data inside the @page
 *    @ops: operations associated with this buffer. See @pipe_buf_operations.
 *    @flags: pipe buffer flags. See above.
 *    @private: private data owned by the ops.
 **/
struct pipe_buffer {
    struct page *page;
    unsigned int offset, len;
    const struct pipe_buf_operations *ops;
    unsigned int flags;
    unsigned long private;
};


/**
 *    struct pipe_inode_info - a linux kernel pipe
 *    @mutex: mutex protecting the whole thing
 *    @wait: reader/writer wait point in case of empty/full pipe
 *    @nrbufs: the number of non-empty pipe buffers in this pipe
 *    @buffers: total number of buffers (should be a power of 2)
 *    @curbuf: the current pipe buffer entry
 *    @tmp_page: cached released page
 *    @readers: number of current readers of this pipe
 *    @writers: number of current writers of this pipe
 *    @files: number of struct file referring this pipe (protected by ->i_lock)
 *    @waiting_writers: number of writers blocked waiting for room
 *    @r_counter: reader counter
 *    @w_counter: writer counter
 *    @fasync_readers: reader side fasync
 *    @fasync_writers: writer side fasync
 *    @bufs: the circular array of pipe buffers
 *    @user: the user who created this pipe
 **/
struct pipe_inode_info {
    struct mutex mutex;
    wait_queue_head_t wait;
    unsigned int nrbufs, curbuf, buffers;
    unsigned int readers;
    unsigned int writers;
    unsigned int files;
    unsigned int waiting_writers;
    unsigned int r_counter;
    unsigned int w_counter;
    struct page *tmp_page;
    struct fasync_struct *fasync_readers;
    struct fasync_struct *fasync_writers;
    struct pipe_buffer *bufs;
    struct user_struct *user;
};

curbuf是當(dāng)前緩存區(qū)的下標(biāo)，每個緩沖區(qū)里有offset和len記錄數(shù)據(jù)寫到的位置，讀寫的時候是要修改這些信息的。

如果兩個進(jìn)程同時進(jìn)行讀或者同時進(jìn)行寫，必要會導(dǎo)致數(shù)據(jù)沖突，所以內(nèi)核會對管道上鎖（pipe_inode_info里的mutex），所以是半雙工的。

比較簡單的實(shí)現(xiàn)可以看xv6的實(shí)現(xiàn)：

struct pipe {
  struct spinlock lock;
  char data[PIPESIZE];
  uint nread;     // number of bytes read
  uint nwrite;    // number of bytes written
  int readopen;   // read fd is still open
  int writeopen;  // write fd is still open
};

直接一塊連續(xù)的內(nèi)存data，用兩個數(shù)字nread、nwrite記錄讀寫數(shù)，通過PIPESIZE取模得到在data上的讀寫位置，用自旋鎖保護(hù)。如果沒有鎖，兩個進(jìn)程就能同時寫數(shù)據(jù)到data和修改nwrite，數(shù)據(jù)也就沖突了，同時讀也同理。

mysql_insert_id(), 高并發(fā)下也是可用的.

1 不要拘泥于瀏覽器和服務(wù)器
2 兩端進(jìn)行交互，發(fā)送請求的一端叫做客戶端(client)，接受請求的一端叫做服務(wù)端(server)。
3 一般我們用的client和server之間通信的協(xié)議，在在網(wǎng)絡(luò)層是IP協(xié)議，傳輸層是基tcp/udp協(xié)議的，在應(yīng)用層是http/ftp協(xié)議。也就是說，不管你http還ftp協(xié)議，都是在傳輸層基tcp協(xié)議的。
4 Socket 接口是TCP/IP網(wǎng)絡(luò)的API，Socket接口定義了許多函數(shù)或例程，用以開發(fā)TCP/IP網(wǎng)絡(luò)上的應(yīng)用程序。
5 這方面的東西一本書都說不完，我簡要說明了一下，如果要了解更多，應(yīng)該去看《計算機(jī)網(wǎng)絡(luò)》相關(guān)書籍。

不用翻墻,而且還可以拿來翻墻

沒有缺的.

只有nginx.conf這個文件是必須的. 別的文件只是按功能分類, 然后由 nginx.conf include一下.

你需要什么功能, 自己或者寫, 或者復(fù)制就好了.

@aferica

這個沒有特定的規(guī)律，哈哈；

像httpd/mysqld 中的d的含義一般是deamon的意思。

1.確認(rèn)一下你的文件目錄下有沒有這個文件
2.確認(rèn)一下這個文件的讀寫權(quán)限是啥

docker rm $(docker ps -a | awk '/training\/webapp/ {print $1}')

redirect和forward是不同的。redirect是服務(wù)端告訴客戶端，你要訪問下一個鏈接，這個時候如果不是把參數(shù)放在session等區(qū)域是不能保存信息的，等于這個時候如果要傳遞token，要么把token放在url上redirect；要么用服務(wù)器端的一個地方保存一下這個token，一般是session，看你的需求，使用redirect之后，才能訪問到token。

Apache，項(xiàng)目文件下有.htaccess文件
內(nèi)容

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteRule  ^$ public/    [L]
    RewriteRule  (.*) public/$1 [L]
</IfModule>

你所有都是滿足你package.json中指定的版本范圍中的最新的話,就不會有響應(yīng)，因?yàn)橐呀?jīng)是最新的沒有可以更新的包。

npm update如果不指定包名(比如npm update lodash)會更新指定位置(local或global)的所有模塊。但是它會按照你package.json中的模塊的版本號來更新，這是一個好特性，如果什么都不考慮直接全部都更新到最新版本，容易出現(xiàn)兼容問題。

比如你的模塊依賴為 "dep1": "~1.1.1"，它表示dep1的包版本為>=1.1.1,<1.2，這樣即使有2.0.0的新版本，你也更新不上去。

具體看npm-update

location / {}這條規(guī)則，由于沒加=限定為完全匹配，所以默認(rèn)的模糊匹配生效，再加上它又在前邊，優(yōu)先級比/apis/這條要高，所以實(shí)際上apis那條規(guī)則永遠(yuǎn)也不會被命中。
解決也簡單，既然你的重點(diǎn)在apis那條規(guī)則上，那干嘛把它放后邊呢？配置時一般會把/放到最后，在其它規(guī)則都沒命中時，才需要它保底的，放前邊它就成截胡的了。

golang 可以看一下這個 github.com/uber-common/cpustat

git config --global url."https://".insteadOf git://

f8app在window安裝教程
http://blog.csdn.net/industri...

直接在ubuntu中打開命令行，執(zhí)行update-grub2應(yīng)該可以吧。命令會掃描系統(tǒng)中的引導(dǎo)文件然后更新到grub2的配置中。重啟在grub2的引導(dǎo)界面應(yīng)該就能看到windows boot