第一篇：,中國人民大學(xué)網(wǎng)絡(luò)教育學(xué)院常見問題人大網(wǎng)院常見問題
一、登錄問題
1.為何輸入用戶名和密碼，總是登錄不了網(wǎng)絡(luò)課堂？ 原因：可能是用戶名和密碼確實輸入有誤。處理辦法：（1）輸入用戶名和密碼時，建議可以先建立一個新的文檔，將用戶名和密碼正確的輸入文檔里，然后點擊“網(wǎng)絡(luò)課堂”后，將用戶名和密碼復(fù)制、粘貼到相應(yīng)位置。
（2）連續(xù)輸入正確的用戶名和密碼后，第四次找回密碼，過半小時以后再測試一下是否可以正常登錄。
（3）如果用戶名和密碼均正確，還是出現(xiàn)登錄不了網(wǎng)絡(luò)課堂的情況，建議先做如下操作：
①在所使用的計算機(jī)上首先運行防病毒軟件檢查病毒、木馬。
②檢查IE瀏覽器的設(shè)置，最好把IE瀏覽器恢復(fù)成初始設(shè)置。③可以更換瀏覽器。
④在出現(xiàn)問題的時候檢查是否可以上網(wǎng)，同時使用其他電腦重復(fù)登錄操作。
2.登錄網(wǎng)絡(luò)課堂時，設(shè)置了“記住我的密碼”或“自動保存”功能，該如何取消呢？ 處理辦法：（1）清除歷史記錄和緩存，“工具” —> “Internet 選項”—>“常規(guī)”—> “刪除cookies”、“刪除文件”、“清空歷史記錄和緩存” —> “確定”。
（2）清除表單和密碼，“工具”—>“Internet選項”—>“內(nèi)容”—>“自動完成”—>“清除表單”、“清除密碼”—>“確定”。
（3）關(guān)閉桌面上所有的IE瀏覽器，重新打開新的IE，再登錄“網(wǎng)絡(luò)課堂”時，會出現(xiàn)如截圖一所示：
截圖一
（4）點擊截圖一“記住我的密碼”前的“對勾”，即取消該功能。再將原來的用戶名和密碼刪除，如截圖二所示：
截圖二
（5）在截圖二的界面，重新輸入新的用戶名和密碼即可。
3.登錄“網(wǎng)絡(luò)課堂”時出現(xiàn)“歡迎您學(xué)習(xí)”的藍(lán)色頁面后無法繼續(xù)進(jìn)入課程學(xué)習(xí)頁面，該如何處理？
原因：現(xiàn)使用的電腦有攔截、過濾功能，需將該功能關(guān)閉。
（1）點擊IE瀏覽器“工具”?“彈出窗口阻止程序”?“關(guān)閉彈出窗口阻止程序”。（2）關(guān)閉桌面上所有的IE瀏覽器，重新打開新的IE瀏覽器，再登錄“網(wǎng)絡(luò)課堂”。若已進(jìn)行以上操作還是無法解決藍(lán)屏問題，可再查看學(xué)院主頁<學(xué)習(xí)專區(qū)>?<課程學(xué)習(xí)常見問題集>中的關(guān)于藍(lán)屏問題的解決方案。
二、課程問題
1.進(jìn)入網(wǎng)絡(luò)課堂以后，沒有課程目錄，該怎么辦？
原因：該問題與IE瀏覽器的安全級別設(shè)置過高有關(guān)。處理辦法：（1）將IE瀏覽器的安全級別設(shè)置為中。
（2）假如調(diào)整了安全級別仍然無法使用，建議嘗試如下方法：
IE瀏覽器“工具” ?? Internet選項??高級 點擊“重置”按鈕，然后重新關(guān)閉所有IE窗口，再次進(jìn)入“網(wǎng)絡(luò)課堂”。IE8.0的“重置”按鈕一般如下圖所示：
若是windows XP系統(tǒng)、IE6.0的配置，如下界面所示，點擊“重置 Web 設(shè)置”，即可。
另外說明：因不同的IE版本，“重置”按鈕的位置可能會不一樣，所以最終還需根據(jù)學(xué)生的IE瀏覽器版本找到相應(yīng)的“重置”按鈕，并進(jìn)行設(shè)置。
2.使用IE8.0的瀏覽器，打開部分課程，會出現(xiàn)頁面顯示不全的情況，如下圖《員工關(guān)系管理》這門課程，該如何處理？
原因：與IE瀏覽器的“兼容性”有關(guān)。處理辦法：根據(jù)下圖紅色圓圈處進(jìn)行操作，將鼠標(biāo)放在倒三角號處，會有一個“兼容性”的字樣出現(xiàn)，點擊一下即可。如下圖所示：
3.在學(xué)習(xí)英語課程時，點擊課程的教師講解后無法播放，提示安裝“MST player”播放器，但按照提示點擊安裝后，先是沒有任何顯示，接著會出現(xiàn)紅色小叉（如下圖所示），該如何處理？
原因：電腦在自動安裝MST播放器時遇到問題，那么可以選擇手動安裝MST播放插件。處理辦法：登錄學(xué)院主頁?<學(xué)習(xí)專區(qū)>?<常用軟件下載>中，根據(jù)電腦安裝系統(tǒng)的不同，手動下載MSTPlayer.rar播放器（適合XP或以下版本）或Vista_MSTPlayer.rar播放器（適合Vista和Win7 版本）。下載后解壓，關(guān)閉所有瀏覽器，按照提示安裝相應(yīng)插件。安裝完成后即可正常播放教師講解內(nèi)容。
4.在播放網(wǎng)絡(luò)課堂中的教師講解時，出現(xiàn)既無圖像又無聲音的情況，該怎么辦？
原因：大部分情況下出現(xiàn)此類問題都與電腦的音視頻編解碼器及播放器有關(guān)。
例：在點擊課程教師講解時，出現(xiàn)黑框，或是黑框一閃就沒有了，可按照以下5個步驟進(jìn)行處理：
（1）首先了解電腦的系統(tǒng)配置，正確下載安裝相應(yīng)的音視頻編解碼器。再次登錄網(wǎng)絡(luò)課堂后，便可以正常播放教師講解中音、視頻內(nèi)容。
現(xiàn)在普遍使用的電腦系統(tǒng)一般分為以下三種類型：
①Win7系統(tǒng)，需下載<學(xué)院主頁>?<學(xué)習(xí)專區(qū)>?<常用軟件下載>中文件名為Win7和Vista兩個音視頻編解碼器。
②Vista系統(tǒng)，需下載<學(xué)院主頁>?<學(xué)習(xí)專區(qū)>?<常用軟件下載>中文件名Vista的一個音視頻編解碼器。
③Windows XP操作系統(tǒng)，則下載<學(xué)院主頁>?<學(xué)習(xí)專區(qū)>?<常用軟件下載>中文件名為“acelp_net.zip”的WMP編解碼器。
（2）下載安裝了相應(yīng)的編解碼器后，仍無法正常播放教師講解，則需卸載電腦中安裝的暴風(fēng)影音等播放器。
（3）將以上2種處理辦法都操作后，還是無法正常播放教師講解，請核查曾經(jīng)是否下載過游戲軟件等，可將其設(shè)置為禁用，最好能卸載相關(guān)軟件。
（4）按照以上3種處理辦法還是無法正常播放教師講解，如有課程光盤，可使用課程光盤來測試一下是否是使用的media player播放器有問題。
具體操作如下：右擊光盤驅(qū)動器?點擊“打開”?雙擊content文件?雙擊kcjj文件后，便可以找到相應(yīng)課程的教師講解內(nèi)容。若教師講解無法播放，則是學(xué)生用戶端的media player播放器有問題，可把現(xiàn)有播放器卸載，再重新下載、安裝一個新版本的media player播放器進(jìn)行測試。建議下載<學(xué)院主頁>?<學(xué)習(xí)專區(qū)>?<常用軟件下載>中文件名為Media Player 9.0版本播放器，若系統(tǒng)不兼容，再下載其他版本media player播放器。
（5）以上所有處理辦法均無法解決教師講解播放問題，建議重裝電腦系統(tǒng)，將使用的電腦系統(tǒng)配置都恢復(fù)到初始設(shè)置，再按照以上的4個步驟進(jìn)行設(shè)置。
5.若在播放大學(xué)英語課程的教師講解時，出現(xiàn)“系統(tǒng)繁忙或當(dāng)前用戶太多，請稍后再試”的字樣，該怎么辦？
處理辦法：可通過撥打?qū)W院咨詢電話010-82500808或使用學(xué)生信箱發(fā)郵件到楊老師信箱（jiaowu@cmr.com.cn）或在楊老師論壇中發(fā)帖這三種方式向?qū)W院反映情況，學(xué)院將盡快處理并及時將處理結(jié)果反饋給學(xué)生。
6.無法正常提交課程作業(yè)，顯示“請勿多次刷屏”，該怎么辦？
原因：可能已經(jīng)超過了規(guī)定的作業(yè)提交時間。處理辦法：（1）清除歷史記錄和緩存，IE瀏覽器 “工具” —> “Internet 選項”—>“清空歷史記錄和緩存” —> “確定”。把桌面上所有的IE瀏覽器全部關(guān)閉，再重新打開學(xué)院主頁，重新登陸網(wǎng)絡(luò)課堂，完成課程作業(yè)。
（2）請在規(guī)定的時間（30分鐘）內(nèi)，完成并提交作業(yè)，請勿超時。（3）如果還是提交不了或顯示超時等，建議換一臺電腦。
7.提交作業(yè)時，并沒有超時，但是提交時仍提示“超時已過期”，該怎么辦？ 原因：IE瀏覽器會緩存記錄以前登錄網(wǎng)頁信息，致使時間累計。
處理辦法：(1)找到IE 瀏覽器“工具”欄—> “Internet選項”—>彈出“Internet選項”窗口—>選擇“常規(guī)”標(biāo)簽—>選擇第二項“Internet臨時文件”—>點擊“刪除文件”—>彈出“刪除文件”小窗口—>勾選“刪除所有脫機(jī)內(nèi)容”—>“確定”，關(guān)閉小窗口—> 再“確定”。
（2）找到IE 瀏覽器“工具”欄—> “Internet選項”—>選擇“常規(guī)”標(biāo)簽點擊“設(shè)置”，彈出設(shè)置窗口—> “檢查網(wǎng)頁所存較新版本”的選項中選擇“每次訪問此頁時檢查” —>點“確定”—>再點“Internet選項”的確定，關(guān)閉“Internet選項”窗口。
（3）重新打開新IE，打開學(xué)院主頁，重新登陸網(wǎng)絡(luò)課堂，完成課程作業(yè)。
8.在新版網(wǎng)絡(luò)課程的“課程學(xué)習(xí)”欄目中，看不到老師的講稿（幻燈片）？
現(xiàn)象：
在新版網(wǎng)絡(luò)課程的“課程學(xué)習(xí)”欄目中，能看到老師講課視頻，但看不到老師的講稿（幻燈片），如下圖：
原因： 新版網(wǎng)絡(luò)課程在觀看老師講課的講稿時需要安裝VGAPlayer插件。
解決方案：
新版網(wǎng)絡(luò)課程請使用IE 瀏覽器觀看課件。
在IE中如出現(xiàn)上圖的提示，則請單擊上圖紅色框線中任意一處，即可安裝ActiveX控件：PowerCreator VGAPlayer。
當(dāng)出現(xiàn)如下畫面時請點擊“安裝”。
如果以上自動安裝遇到問題，仍無法看見老師的講稿（幻燈片），請手動下載“VGAPlayer插件”并安裝，下載地址為 ：
http://
三、值機(jī)答疑問題
無法正常進(jìn)入值機(jī)答疑，該怎么辦？
原因：可能是還沒有安裝新的 V2.9版本答疑記錄播放器。處理辦法：（1）下載、安裝新的V2.9版本答疑記錄播放器，下載位置如下截圖，：
（2）如果以前下載過舊的版本，需先將舊的版本卸載以后，再安裝新的V2.9版本答疑記錄播放器。
第二篇：網(wǎng)絡(luò)編程常見問題總結(jié)
網(wǎng)絡(luò)編程常見問題總結(jié)
網(wǎng)絡(luò)編程常見問題總結(jié) 串講(一)
網(wǎng)絡(luò)編程常見問題總結(jié)
在網(wǎng)絡(luò)程序中遇到的一些問題進(jìn)行了總結(jié), 這里主要針對的是我們常用的TCP socket相關(guān)的總結(jié)，可能會存在錯誤，有任何問題歡迎大家提出.對于網(wǎng)絡(luò)編程的更多詳細(xì)說明建議參考下面的書籍
《UNIX網(wǎng)絡(luò)編程》 《TCP/IP 詳解》 《Unix環(huán)境高級編程》
非阻塞IO和阻塞IO：
在網(wǎng)絡(luò)編程中對于一個網(wǎng)絡(luò)句柄會遇到阻塞IO和非阻塞IO的概念, 這里對于這兩種socket先做一下說明
基本概念：
socket的阻塞模式意味著必須要做完IO操作（包括錯誤）才會返回。非阻塞模式下無論操作是否完成都會立刻返回，需要通過其他方式來判斷具體操作是否成功。
設(shè)置：
一般對于一個socket是阻塞模式還是非阻塞模式有兩種方式 fcntl設(shè)置和recv,send系列的參數(shù).fcntl函數(shù)可以將一個socket句柄設(shè)置成非阻塞模式:
flags = fcntl(sockfd, F_GETFL, 0);fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);設(shè)置之后每次的對于sockfd的操作都是非阻塞的
recv, send函數(shù)的最后有一個flag參數(shù)可以設(shè)置成MSG_DONTWAIT臨時將sockfd設(shè)置為非阻塞模式,而無論原有是阻塞還是非阻塞。recv(sockfd, buff, buff_size, MSG_DONTWAIT);send(scokfd, buff, buff_size, MSG_DONTWAIT);區(qū)別:
讀:
讀本質(zhì)來說其實不能是讀,在實際中, 具體的接收數(shù)據(jù)不是由這些調(diào)用來進(jìn)行,是由于系統(tǒng)底層自動完成的,read也好,recv也好只負(fù)責(zé)把數(shù)據(jù)從底層緩沖copy到我們指定的位置.對于讀來說(read, 或者 recv)，在阻塞條件下如果沒有發(fā)現(xiàn)數(shù)據(jù)在網(wǎng)絡(luò)緩沖中會一直等待，當(dāng)發(fā)現(xiàn)有數(shù)據(jù)的時候會把數(shù)據(jù)讀到用戶指定的緩沖區(qū)，但是如果這個時候讀到的數(shù)據(jù)量比較少，比參數(shù)中指定的長度要小，read并不會一直等待下去，而是立刻返回。read的原則是數(shù)據(jù)在不超過指定的長度的時候有多少讀多少，沒有數(shù)據(jù)就會一直等待。所以一般情況下我們讀取數(shù)據(jù)都需要采用循環(huán)讀的方式讀取數(shù)據(jù)，一次read完畢不能保證讀到我們需要長度的數(shù)據(jù)，read完一次需要判斷讀到的數(shù)據(jù)長度再決定是否還需要再次讀取。在非阻塞的情況下，read的行為是如果發(fā)現(xiàn)沒有數(shù)據(jù)就直接返回，如果發(fā)現(xiàn)有數(shù)據(jù)那么也是采用有多少讀多少的進(jìn)行處理．對于讀而言，阻塞和非阻塞的區(qū)別在于沒有數(shù)據(jù)到達(dá)的時候是否立刻返回．
recv中有一個 MSG_WAITALL的參數(shù) recv(sockfd, buff, buff_size, MSG_WAITALL), 在正常情況下 recv是會等待直到讀取到buff_size長度的數(shù)據(jù)，但是這里的WAITALL也只是盡量讀全，在有中斷的情況下recv還是可能會 被打斷，造成沒有讀完指定的buff_size的長度。所以即使是采用recv + WAITALL參數(shù)還是要考慮是否需要循環(huán)讀取的問題，在實驗中對于多數(shù)情況下recv還是可以讀完buff_size，所以相應(yīng)的性能會比直接read 進(jìn)行循環(huán)讀要好一些。不過要注意的是這個時候的sockfd必須是處于阻塞模式下，否則WAITALL不能起作用。
寫:
寫的本質(zhì)也不是進(jìn)行發(fā)送操作,而是把用戶態(tài)的數(shù)據(jù)copy到系統(tǒng)底層去,然后再由系統(tǒng)進(jìn)行發(fā)送操作,返回成功只表示數(shù)據(jù)已經(jīng)copy到底層緩沖,而不表示數(shù)據(jù)以及發(fā)出,更不能表示對端已經(jīng)接收到數(shù)據(jù).對于write(或 者send)而言，在阻塞的情況是會一直等待直到write完全部的數(shù)據(jù)再返回．這點行為上與讀操作有 所不同，究其原因主要是讀數(shù)據(jù)的時候我們并不知道對端到底有沒有數(shù)據(jù)，數(shù)據(jù)是在什么時候結(jié)束發(fā)送的，如果一直等待就可能會造成死循環(huán)，所以并沒有去進(jìn)行這方面的處理；而對于write, 由于需要寫的長度是已知的，所以可以一直再寫，直到寫完．不過問題是write是可能被打斷造成write一次只write一部分?jǐn)?shù)據(jù), 所以write的過程還是需要考慮循環(huán)write, 只不過多數(shù)情況下一次write調(diào)用就可能成功.非阻塞寫的情況下，是采用可以寫多少就寫多少的策略．與讀不一樣的地方在于，有多少讀多少是由網(wǎng)絡(luò)發(fā)送的那一端是否有數(shù)據(jù)傳輸?shù)綖闃?biāo)準(zhǔn)，但是對于可以寫多少是由本地的網(wǎng)絡(luò)堵塞情況為標(biāo)準(zhǔn)的，在網(wǎng)絡(luò)阻塞嚴(yán)重的時候，網(wǎng)絡(luò)層沒有足夠的內(nèi)存來進(jìn)行寫操作，這時候就會出現(xiàn)寫不成功的情況，阻塞情況下會盡可能(有可能被中斷)等待到數(shù)據(jù)全部發(fā)送完畢，對于非阻塞的情況就是一次寫多少算多少,沒有中斷的情況下也還是會出現(xiàn)write到一部分的情況.網(wǎng)絡(luò)編程常見問題總結(jié) 串講(二)
超時控制:
對于網(wǎng)絡(luò)IO，我們一般情況下都需要超時機(jī)制來避免進(jìn)行操作的線程被handle住，經(jīng)典的做法就是采用select+非阻塞IO進(jìn)行判斷，select在超時時間內(nèi)判斷是否可以讀寫操作，然后采用非堵塞讀寫,不過一般實現(xiàn)的時候讀操作不需要設(shè)置為非堵塞，上面已經(jīng)說過讀操作只有在沒有數(shù)據(jù)的 時候才會阻塞，select的判斷成功說明存在數(shù)據(jù)，所以即使是阻塞讀在這種情況下也是可以做到非阻塞的效果，就沒有必要設(shè)置成非阻塞的情況了．
這部分的代碼可以參考ullib中ul_sreado_ms_ex和ul_swriteo_ms_ex．
采用ul_sreado_ms_ex讀數(shù)據(jù)也是不能保證返回大于0就一定讀到指定的數(shù)據(jù)長度, 對于讀寫操作, 都是需要判斷返回的讀長度或者寫長度是否是需要的長度, 不能簡單的判斷一下返回值是否小于0.對于ul_sreado_ms_ex的情況如果出現(xiàn)了發(fā)送端數(shù)據(jù)發(fā)送一半就被close掉的情況就有可能導(dǎo)致接收端讀不到完整的數(shù)據(jù)包.errno 只有在函數(shù)返回值為負(fù)的時候才有效,如果返回0或者大于0的數(shù), errno 的結(jié)果是無意義的.有些時候 會出現(xiàn)read到0，但是我們認(rèn)為是錯誤的情況然后輸出errno造成誤解，一般建議在這種情況要同時輸出返回值和errno的結(jié)果，有些情況由于只有errno造成了對于問 題的判斷失誤。
長連接和短連接的各種可能的問題及相應(yīng)的處理
這里主要是發(fā)起連接的客戶端的問題,這里列出的問題主要是在采用同步模型的情況下才會存在的問題.短連接:
采用短連接的情況一般是考慮到下面的一些問題: 后端服務(wù)的問題, 考慮最簡單的情況下一個線程一個連接, 如果這個連接采用了長連接那么就需要我們處理連接的線程和后端保持一一對應(yīng),然后按照某些原則進(jìn)行處理(n對n的關(guān)系), 但由于一方面服務(wù)器可能增加,這樣導(dǎo)致需要前后端保持一致,帶來了更多的麻煩,另一方面線程數(shù)上不去對應(yīng)處理能力也會產(chǎn)生影響,而短連接每次連接的時候只 需要關(guān)注當(dāng)前的機(jī)器,問題相對會少一些.其實這個問題可以采用連接池的方式來解決,后面會提到.不需要考慮由于異常帶來的臟數(shù)據(jù)。負(fù)載均衡方面可以簡單考慮, 無論線程數(shù)是多少還是后端服務(wù)器的數(shù)量是多少都沒有關(guān)系, 每次考慮單個連接就可以了.當(dāng)然如果負(fù)載邏輯簡單,并且機(jī)器相對固定,一個線程一個長連接問題也不大.規(guī)避一些問題, 在過去有些情況下出現(xiàn)長連接大延時,數(shù)據(jù)沒響應(yīng)等問題, 測試的時候發(fā)現(xiàn)換短連接問題就解決了,由于時間關(guān)系就沒有再繼續(xù)追查, 事實上這些問題現(xiàn)在基本上都已經(jīng)定位并且有相關(guān)的解決方案了.不足:
效率不足, 由于連接操作一般會有50ns~200ns的時間消耗,導(dǎo)致短連接需要消耗更多的時間會產(chǎn)生TIME_WAIT問題,需要做更多的守護(hù)
長連接:
長連接相比短連接減少了連接的時間消耗, 可以承受更高的負(fù)載.但在使用的時候需要考慮一些問題臟數(shù)據(jù), 在一些特殊情況(特別是邏輯錯誤的情況下)會存在一些我們并不需要的數(shù)據(jù).這個時候的處理比較安全的方式是一旦檢測到就關(guān)閉連接, 檢測的方式在在發(fā)起請求前用前面為什么socket寫錯誤,但用recv檢查依然成功? 介紹的方式進(jìn)行檢查.不過有些程序會采用繼續(xù)讀把所有不需要的數(shù)據(jù)讀完畢(讀到 EAEGIN), 不過這種方式過分依賴邏輯了,存在了一定的風(fēng)險.不如直接斷開來的簡單 后端連接, 前面也提到了 在這種情況我們一般會采用連接池的方式來解決問題比如(public/connectpool中就可以維護(hù)不同的連接,使每個線程都可以均勻的獲取到句 柄)服務(wù)端的處理這個時候需要考慮連接的數(shù)量,簡單的方式就是一個長連接一個線程, 但是線程也不能無限增加(增加了,可能造成大量的上下文切換使的性能下降).我們一般在長連接的情況采用pendingpool的模型, 通過一個異步隊列來緩沖, 這樣不需要考慮客戶端和服務(wù)端的線程數(shù)問題,可以任意配置(可以通過線下測試選擇合適的線程數(shù))
一些特殊的問題, 主要是長連接的延時 在后面的FAQ中會有詳細(xì)的說明.一般來說,對于我們多數(shù)的內(nèi)部業(yè)務(wù)邏輯都是可以采用長連接模式,不會產(chǎn)生太多的問題.網(wǎng)絡(luò)編程常見問題總結(jié) 串講(三)
主要線程模型優(yōu)缺點和注意事項
這里所列出的線程模型，目前在我們的public/ub下都有相關(guān)的實現(xiàn)，在 ubFAQ中也有相關(guān)的說明，這里主要針對這些模 型的使用做相關(guān)的說明
最簡單的線程模型 同時啟動多個線程，每個線程都采用accept的方式進(jìn)行阻塞獲取連接(具體實現(xiàn)上一般是先select在accept, 一方面規(guī)避低內(nèi)核的驚群效應(yīng),另一方面可以做到優(yōu)雅退出).多個線程競爭一個連接, 拿到連接的線程就進(jìn)行自己的邏輯處理, 包括讀寫IO全部都在一個線程中進(jìn)行.短連接每次重新accept, 長連接,第一次的時候accept然后反復(fù)使用.一般來說在總連接數(shù)很少的情況下效果會比較好,相對適用于少量短連接(可以允許比線程數(shù)多一些)和不超過線程總數(shù)的長連接(超過的那些連接,除非 accept的連接斷開,否則不可能會有線程對它進(jìn)行accept).但如果同一時候連接數(shù)過多會造成沒有工作線程與客戶端進(jìn)行連接，客戶端會出現(xiàn)大量的連接失敗, 因為這個時候線程可能存在不能及時accept造成超時問題, 在有重試機(jī)制的情況下可能導(dǎo)致問題更糟糕.有些程序在出現(xiàn)幾次超時之后會長時間一直有連接超時往往就是在這種情況下發(fā)生的.這種模型的最大優(yōu)點在于編寫簡單, 在正常情況下工作效果不錯.在public/ub中的xpool就是屬于這種模型,建議針對連接數(shù)少的服務(wù)進(jìn)行使用,比如一些一對一的業(yè)務(wù)邏輯.生產(chǎn)者消費者模型
普通線程模型在長連接方面存在使用限制(需要對于線程數(shù)進(jìn)行變化, 而線程又不是無限的), 短連接在處理同時大量連接(比如流量高峰期)的時候存在問題.生產(chǎn)者消費者模型是可以把這種影響減少.對于有數(shù)據(jù)的活動連接放到異步隊列中, 其他線程競爭這個隊列獲取句柄然后進(jìn)行相關(guān)的操作.由于accept是專門的線程進(jìn)行處理, 出現(xiàn)被handle的情況比較少,不容易出現(xiàn)連接失敗的情況.在大流量的情況下有一定的緩沖,雖然有些請求會出現(xiàn)延時,但只要在可以接受的范圍內(nèi),服務(wù)還 是可以正常進(jìn)行.一般來說隊列的長度主要是考慮可以接受的延時程度.這種模式也是我們現(xiàn)在許多服務(wù)比較常用的模型.可以不用關(guān)心客戶端和服務(wù)的線程數(shù)對應(yīng)關(guān)系，業(yè)務(wù)邏輯上也是比較簡單的。
但這種模式在編程的 時候,對于長連接有一個陷阱，判斷句柄是否可讀寫以前一般采用的是select, 如果長連接的連接數(shù)比工作線程還少，當(dāng)所有的連接都被處理了，有連接需要放回pool中，而這個時候如果正常建立連接的監(jiān)聽線程正好處于select狀 態(tài)，這個時候必須要等到 select超時才能重新將連接放入select中進(jìn)行監(jiān)聽，因為這之前被放入select進(jìn)行監(jiān)聽的處理socket為空，不會有響應(yīng)，這個時候由于時 間的浪費造成l長連接的性能下降。一般來說某個連接數(shù)少,某個連接特別活躍就可能造成問題.過去的一些做法是控制連接數(shù)和服務(wù)端的工作線程數(shù)以及通過監(jiān)聽一個管道fd,在工作線程結(jié)束每次都激活這個fd跳出這次select來控制?，F(xiàn)在的2.6 內(nèi)核中的epoll在判斷可讀寫的時候不會存在這個問題(epoll在進(jìn)行監(jiān)聽的時候,其它線程放入或者更改, 在epoll_wait的時候是可以馬上激活的), 我們現(xiàn)在的服務(wù)多采用epoll代替select來解決這個, 但是主要的邏輯沒有變化.ub_server中epool和public/ependingpool都是采用種模式
異步模型
這里只做一些簡單的介紹。上 面兩者模型本質(zhì)都是同步的處理業(yè)務(wù)邏輯,在一個線程中處理了讀請求,業(yè)務(wù)邏輯和寫回響應(yīng)三個過程(很多業(yè)務(wù)更復(fù)雜，但是都是可以做相應(yīng)的拆封的）, 但是讀和寫這兩個IO的處理往往需要阻塞等待, 這樣造成了線程被阻塞, 如果要應(yīng)付慢連接(比如外圍抓取等待的時間是秒級的甚至更多), 在等待的時候其實CPU沒有干多少事情, 這個時候就造成了浪費.一種考慮是增加線程數(shù),通過提高并發(fā)來解決這個問題, 但是我們目前的線程數(shù)還是有限的,不可能無限增加.而且線程的增加會帶來cpu對于上下文切換的代價,另一方面多個線程從一個隊列中獲取可用連接, 這里存在互斥線程多的時候會導(dǎo)致性能下降,當(dāng)然這里可以通過把一個隊列改多隊列減少互斥來實現(xiàn).引入異步化的處理, 就是把對于IO的等待采用IO復(fù)用的方式,專門放入到一個或者若干個線程中去, 處理主邏輯的程序可以被釋放出來, 只有在IO處理完畢才進(jìn)行處理, 這樣可以提高CPU的使用率，減少等待的時間.一般情況下幾個線程(一般和CPU的核數(shù)相當(dāng))可以應(yīng)付很大的流量請求 public/kylin , ub/ub(ub事件模型)都是基于純異步思想的異步框架。而ub中的appool是簡化版本將原本ub框架中網(wǎng)絡(luò)IO處理進(jìn)行了異步化，不過目前只支持 采用nshead頭的模式。網(wǎng)絡(luò)編程常見問題總結(jié) 串講(四)
為什么網(wǎng)絡(luò)程序會沒有任何預(yù)兆的就退出了
一般情況都是沒有設(shè)置忽略PIPE信號，在我們的環(huán)境中當(dāng)網(wǎng)絡(luò)觸發(fā)broken pipe(一般情況是write的時候，沒有write完畢，接受端異常斷開了)，系統(tǒng)默認(rèn)的行為是直接退出。在我們的程序中一般都要在啟動的時候加上 signal(SIGPIPE, SIG_IGN);來強制忽略這種錯誤
write出去的數(shù)據(jù), read的時候知道長度嗎?
嚴(yán)格來說, 交互的兩端, 一端write調(diào)用write出去的長度, 接收端是不知道具體要讀多長的.這里有幾個方面的問題
write 長度為n的數(shù)據(jù), 一次write不一定能成功(雖然小數(shù)據(jù)絕大多數(shù)都會成功), 需要循環(huán)多次write，write雖然成功,但是在網(wǎng)絡(luò)中還是可能需要拆包和組包, write出來的一塊數(shù)據(jù), 在接收端底層接收的時候可能早就拆成一片一片的多個數(shù)據(jù)包.TCP層中對于接收到的數(shù)據(jù)都是把它們放到緩沖中, 然后read的時候一次性copy, 這個時候是不區(qū)分一次write還是多次write的。所以對于網(wǎng)絡(luò)傳輸中 我們不能通過簡單的read調(diào)用知道發(fā)送端在這次交互中實際傳了多少數(shù)據(jù).一般來說對于具體的交互我們一般采取下面的方式來保證交互的正確,事先約定好長度, 雙方都采用固定長度的數(shù)據(jù)進(jìn)行交互, read, write的時候都是讀取固定的長度.但是這樣的話升級就必須考慮兩端同時升級的問題。特殊的結(jié)束符或者約定結(jié)束方式, 比如http頭中采用連續(xù)的/r/n來做頭部的結(jié)束標(biāo)志.也有一些采用的是短連接的方式, 在read到0的時候,傳輸變長數(shù)據(jù)的時候一般采用定長頭部+變長數(shù)據(jù)的方式, 這個時候在定長的頭部會有一個字段來表示后面的變長數(shù)據(jù)的長度, 這種模式下一般需要讀取兩次確定長度的數(shù)據(jù).我們現(xiàn)在內(nèi)部用的很多都是這樣的模式.比如public/nshead就是這樣處理, 不過nshead作為通用庫另外考慮了采用 通用定長頭+用戶自定義頭+變長數(shù)據(jù)的接口。
總的來說read讀數(shù) 據(jù)的時候不能只通過read的返回值來判斷到底需要讀多少數(shù)據(jù), 我們需要額外的約定來支持, 當(dāng)這種約定存在錯誤的時候我們就可以認(rèn)為已經(jīng)出現(xiàn)了問題.另外對于write數(shù)據(jù)來說, 如果相應(yīng)的數(shù)據(jù)都是已經(jīng)準(zhǔn)備好了那這個時候也是可以把數(shù)據(jù)一次性發(fā)送出去,不需要調(diào)用了多次write.一般來說write次數(shù)過多也會對性能產(chǎn)生影響,另一個問題就是多次連續(xù)可能會產(chǎn)生延時問題,這個參看下面有關(guān)長連接延時的部分問題.小提示
上面提到的都是TCP的情況, 不一定適合其他網(wǎng)絡(luò)協(xié)議.比如在UDP中 接收到連續(xù)2個UDP包, 需要分別讀來次才讀的出來, 不能像TCP那樣,一個read可能就可以成功(假設(shè)buff長度都是足夠的)。如何查看和觀察句柄泄露問題 一般情況句柄只有1024個可以使用，所以一般情況下比較容易出現(xiàn)，也可以通過觀察/proc/進(jìn)程號/fd來觀察。
另外可以采用valgrind來檢查，valgrind參數(shù)中加上--track-fds = yes 就可以看到最后退出的時候沒有被關(guān)閉的句柄，以及打開句柄的位置
為什么socket寫錯誤,但用recv檢查依然成功?
首先采用recv檢查連接的是基于我們目前的一個請求一個應(yīng)答的情況對于客戶端的請求,邏輯一般是這樣 建立連接->發(fā)起請求->接受應(yīng)答->長連接繼續(xù)發(fā)請求
recv檢查一般是這樣采用下面的方式: ret = recv(sock, buf, sizeof(buf), MSG_DONTWAIT);通過判斷ret 是否為-1并且errno是EAGAIN 在非堵塞方式下如果這個時候網(wǎng)絡(luò)沒有收到數(shù)據(jù), 這個時候認(rèn)為網(wǎng)絡(luò)是正常的。這是由于在網(wǎng)絡(luò)交換模式下 我們作為一個客戶端在發(fā)起請求前, 網(wǎng)絡(luò)中是不應(yīng)該存在上一次請求留下來的臟數(shù)據(jù)或者被服務(wù)端主動斷開(服務(wù)端主動斷開會收到FIN包,這個時候是recv返回值為0), 異常斷開會返回錯誤.當(dāng)然這種方式來判斷連接是否存在并不是非常完善,在特殊的交互模式(比如異步全雙工模式)或者延時比較大的網(wǎng)絡(luò)中都是存在問題的,不過對于我們目前內(nèi)網(wǎng)中的交互模式還是基本適用的.這種方式和socket寫錯誤并不矛盾, 寫數(shù)據(jù)超時可能是由于網(wǎng)慢或者數(shù)據(jù)量太大等問題, 這時候并不能說明socket有錯誤, recv檢查完全可能會是正確的.一般來說遇到socket錯誤,無論是寫錯誤還讀錯誤都是需要關(guān)閉重連.為什么接收端失敗，但客戶端仍然是write成功
這個是正常現(xiàn)象，write數(shù)據(jù)成功不能表示數(shù)據(jù)已經(jīng)被接收端接收導(dǎo)致，只能表示數(shù)據(jù)已經(jīng)被復(fù)制到系統(tǒng)底層的緩沖(不一定發(fā)出), 這個時候的網(wǎng)絡(luò)異常都是會造成接收端接收失敗的．長連接的情況下出現(xiàn)了不同程度的 延時 在一些長連接的條件下, 發(fā)送一個小的數(shù)據(jù)包,結(jié)果會發(fā)現(xiàn)從數(shù)據(jù)write成功到接收端需要等待一定的時間后才能接收到, 而改成短連接這個現(xiàn)象就消失了(如果沒有消失，那么可能網(wǎng)絡(luò)本身確實存在延時的問題，特別是跨機(jī)房的情況下）在長連接的處理中出現(xiàn)了延時，而且時間固定，基本都是40ms, 出現(xiàn)40ms延時最大的可能就是由于沒有設(shè)置TCP_NODELAY 在長連接的交互中,有些時候一個發(fā)送的數(shù)據(jù)包非常的小,加上一個數(shù)據(jù)包的頭部就會導(dǎo)致浪費,而且由于傳輸?shù)臄?shù)據(jù)多了,就可能會造成網(wǎng)絡(luò)擁塞的情況, 在系統(tǒng)底層默認(rèn)采用了Nagle算法,可以把連續(xù)發(fā)送的多個小包組裝為一個更大的數(shù)據(jù)包然后再進(jìn)行發(fā)送.但是對于我們交互性的應(yīng)用程序意義就不大了,在這種情況下我們發(fā)送一個小數(shù)據(jù)包的請求,就會立刻進(jìn)行等待,不會還有后面的數(shù)據(jù)包一起發(fā)送, 這個時候Nagle算法就會產(chǎn)生負(fù)作用,在我們的環(huán)境下會產(chǎn)生40ms的延時,這樣就會導(dǎo)致客戶端的處理等待時間過長, 導(dǎo)致程序壓力無法上去.在代碼中無論是服務(wù)端還是客戶端都是建議設(shè)置這個選項,避免某一端造成延時。所以對于長連接的情況我們建議都需要設(shè)置TCP_NODELAY, 在我們的ub框架下這個選項是默認(rèn)設(shè)置的.小提示:
對于服務(wù)端程序而言, 采用的模式一般是
bind-> listen-> accept, 這個時候accept出來的句柄的各項屬性其實是從listen的句柄中繼承, 所以對于多數(shù)服務(wù)端程序只需要對于listen進(jìn)行監(jiān)聽的句柄設(shè)置一次TCP_NODELAY就可以了,不需要每次都accept一次.設(shè)置了NODELAY選項但還是時不時出現(xiàn)10ms(或者某個固定值)的延時 這種情況最有可能的就是服務(wù)端程序存在長連接處理的缺陷.這種情況一般會發(fā)生在使用我們的pendingpool模型(ub中的cpool)情況下,在 模型的說明中有提到.由于select沒有及時跳出導(dǎo)致一直在浪費時間進(jìn)行等待.上面的２個問題都處理了，還是發(fā)現(xiàn)了40ms延時？
協(xié)議棧在發(fā)送包的時候，其實不僅受到TCP_NODELAY的影響，還受到協(xié)議棧里面擁塞窗口大小的影響.在連接發(fā)送多個小數(shù)據(jù)包的時候會導(dǎo)致數(shù)據(jù)沒有及時發(fā)送出去.這里的40ms延時其實是兩方面的問題: 對于發(fā)送端, 由于擁塞窗口的存在,在TCP_NODELAY的情況,如果存在多個數(shù)據(jù)包,后面的數(shù)據(jù)包可能會有延時發(fā)出的問題.這個時候可以采用 TCP_CORK參數(shù), TCP_CORK 需要在數(shù)據(jù)write前設(shè)置,并且在write完之后取消,這樣可以把write的數(shù)據(jù)發(fā)送出去(要注意設(shè)置TCP_CORK的時候不能與TCP_NODELAY混用,要么不設(shè)置TCP_NODELAY要么就先取消TCP_NODELAY)但是在做了上 面的設(shè)置后可能還是會導(dǎo)致40ms的延時, 這個時候如果采用tcpdump查看可以注意是發(fā)送端在發(fā)送了數(shù)據(jù)包后,需要等待服務(wù)端的一個ack后才會再次發(fā)送下一個數(shù)據(jù)包,這個時候服務(wù)端出現(xiàn)了延 時返回的問題.對于這個問題可以通過設(shè)置server端TCP_QUICKACK選項來解決.TCP_QUICKACK可以讓服務(wù)端盡快的響應(yīng)這個ack包.這個問題的主要原因比較復(fù)雜,主要有下面幾個方面
當(dāng)TCP協(xié)議棧收到數(shù)據(jù)的時候, 是否進(jìn)行ACK響應(yīng)(沒有響應(yīng)是不會發(fā)下一個包的），在我們linux上返回ack包是下面這些條件中的一個接收的數(shù)據(jù)足夠多
處于快速回復(fù)模式（TCP_QUICKACK）
存在亂序的包，如果有數(shù)據(jù)馬上返回給發(fā)送端，ACK也會一起跟著發(fā)送
如果都不滿足上面的條件，接收方會延時40ms再發(fā)送ACK，這個時候就造成了延時。
但是對于上面的情況即使是采用TCP_QUICKACK,服務(wù)端也不能保證可以及時返回ack包，因為快速回復(fù)模式在一些情況下是會失效(只能通過修改內(nèi)核來實現(xiàn))目前的解決方案只能是通過修改內(nèi)核來解決這個問題，STL的同學(xué)在 內(nèi)核中增加了參數(shù)可以控制這個問題。
會出現(xiàn)這種情況的主要是連接發(fā)送多個小數(shù)據(jù)包或者采用了一些異步雙工的編程模式，主要的解決方案有下面幾種對于連續(xù)的多個小數(shù)據(jù)包，盡量把他們打到一個buffer中間, 不過會有內(nèi)存復(fù)制的問題(采用writev方式發(fā)送多個小數(shù)據(jù)包，不過writev也存在一個問題就是發(fā)送的數(shù)據(jù)包個數(shù)有限制，如果超過了IOV_MAX（我們的限制一般是1024)，依然可能會出現(xiàn)問題，因為writev只能保證在IOV_MAX范圍內(nèi)的數(shù)據(jù)是按照連續(xù)發(fā)送的。
writev或者大buffer的方式在異步雙工模式下是無法工作，這個時候只能通過系統(tǒng)方式來解決?？蛻舳?不設(shè)置TCP_NODELAY選項，發(fā)送數(shù)據(jù)前先打開TCP_CORK選項，發(fā)送完后再關(guān)閉TCP_CORK，服務(wù)端開啟TCP_QUICKACK選項
采用STL修改的內(nèi)核5-6-0-0，打開相關(guān)參數(shù)。
網(wǎng)絡(luò)編程常見問題總結(jié) 串講(五)
TIME_WAIT有什么樣的影響?
對于TIME_WAIT的出現(xiàn)具體可以參考<
對于服務(wù)器端如果出現(xiàn)TIME_WAIT狀態(tài)，是不會產(chǎn)生端口不夠用的情況，但是TIME_WAIT過多在服務(wù)器端還是會占用一定的內(nèi)存資源，在/proc/sys/net/ipv4/tcp_max_xxx 中我們可以系統(tǒng)默認(rèn)情況下的所允許的最大TIME_WAIT的個數(shù)，一般機(jī)器上都是180000, 這個對于應(yīng)付一般程序已經(jīng)足夠了．但對于一些壓力非常大的程序而言，這個時候系統(tǒng)會不主動進(jìn)入TIME_WAIT狀態(tài)而且是直接跳過，這個時候如果去看 dmsg中的信息會看到 “TCP: time wait bucket table overflow” , 一般來說這種情況是不會產(chǎn)生太多的負(fù)面影響, 這種情況下后來的socket在關(guān)閉時不會進(jìn)入TIME_WAIT狀態(tài)，而是直接發(fā)RST包, 并且關(guān)閉socket.不過還是需要關(guān)注為什么會短時間內(nèi)出現(xiàn)這么大量的請求。
小提示: 如果需要設(shè)置SO_LINGER選項, 需要在FD連接上之后設(shè)置才有效果
: O% B: j3 o/ A
什么情況下會出現(xiàn)CLOSE_WAIT狀態(tài)？
一般來說，連接的一端在被動關(guān)閉的情況下，已經(jīng)接收到FIN包(對端調(diào)用close)后，這個時候如果接收到FIN包的一端沒有主動close就會出 現(xiàn)CLOSE_WAIT的情況。一般來說，對于普通正常的交互，處于CLOSE_WAIT的時間很短，一般的邏輯是檢測到網(wǎng)絡(luò)出錯，馬上關(guān)閉。但是在一些情況下會出現(xiàn)大量的CLOS_WAIT, 有的甚至維持很長的時間，這個主要有幾個原因：
沒有正確處理網(wǎng)絡(luò)異常，特別是read 0的情況，一般來說被動關(guān)閉的時候會出現(xiàn)read 返回0的情況。一般的處理的方式在網(wǎng)絡(luò)異常的情況下就主動關(guān)閉連接句柄泄露了，句柄泄露需要關(guān)閉的連接沒有關(guān)閉而對端又主動斷開的情況下也會出現(xiàn)這樣的問 題。連接端采用了連接池技術(shù)，同時維護(hù)了較多的長連接（比如ub_client, public/connectpool)，同時服務(wù)端對于空閑的連接在一定的時間內(nèi)會主動斷開(比如ub_server, ependingpool都有這樣的機(jī)制).如果服務(wù)端由于超時或者異常主動斷開，客戶端如果沒有連接檢查的機(jī)制，不會主動關(guān)閉這個連接，比如ub_client的機(jī)制就是長連接建立后除非到使用的時候進(jìn)行連接檢查，否則不會主動斷開連接。這個時候在建立連接的一端就會出現(xiàn)CLOSE_WAIT狀態(tài)。這個時候的狀態(tài)一般來說是安全（可控的，不會超過最大連接數(shù)).在com 的connectpool 2中這種情況下可以通過打開健康檢查線程進(jìn)行主動檢查，發(fā)現(xiàn)斷開后主動close.網(wǎng)絡(luò)編程常見問題總結(jié) 串講(六)順序發(fā)送數(shù)據(jù)，接收端出現(xiàn)亂序接收到的情況：
網(wǎng)絡(luò)壓力大的情況下,有時候會出現(xiàn),發(fā)送端是按照順序發(fā)送, 但是接收端接收的時候順序不對.一般來說在正常情況下是不會出現(xiàn)數(shù)據(jù)順序錯誤的情況, 但某些異常情況還是有可能導(dǎo)致的.在我們的協(xié)議棧中,服務(wù)端每次建立連接其實都是從accpet所在的隊列中取出一個已經(jīng)建立的fd, 但是在一些異常情況下,可能會出現(xiàn)短時間內(nèi)建立大量連接的情況, accept的隊列長度是有限制，這里其實有兩個隊列，一個完成隊列另一個是未完成隊列，只有完成了三次握手的連接會放到完成隊列中。如果在短時間內(nèi)accept中的fd沒有被取出導(dǎo)致隊 列變滿，但未完成隊列未滿，這個時候連接會在未完成隊列中，對于發(fā)起連接的一端來說表現(xiàn)的情況是連接已經(jīng)成功，但實際上連接本身并沒有完成，但這個時候我們依然可以發(fā)起寫操作并且成 功，只是在進(jìn)行讀操作的時候，由于對端沒有響應(yīng)會造成讀超時。對于超時的情況我們一般就把連接直接close關(guān)閉了，但是句柄雖然被關(guān)閉了，但是由于TIME_WAIT狀態(tài)的存在，TCP還是會進(jìn)行重傳。在重傳的時候，如果完成隊列有句柄被處理，那么此時會完成三次握手建立連接，這個時候服務(wù)端照樣會進(jìn)行正常的處理（不過在寫響應(yīng)的 時候可能會發(fā)生錯誤）。從接收上看，由于重傳成功的情況我們不能控制，對于接收端來說就可能出現(xiàn)亂序的情況。完成隊列的長度和未完成隊列的長度由listen時候的baklog決定（(ullib庫中ul_tcplisten的最后一個參數(shù)),在我們的 linux環(huán)境中baklog是完成隊列的長度，baklog * 1.5是兩個隊列的總長度（與一些書上所說的兩個隊列長度不超過baklog有出入).兩個隊列的總長度最大值限制是128, 既使設(shè)置的結(jié)果超過了128也會被自動改為128。128這個限制可以通過 系統(tǒng)參數(shù) /proc/sys/net/core/somaxconn 來更改, 在我們 5-6-0-0 內(nèi)核版本以后,STL將其提高到2048.另外客戶端也可以考慮使用SO_LINGER參數(shù)通過強制關(guān)閉連接來處理這個問題，這樣在close以后就不啟用重傳機(jī)制。另外的考慮就是對重試機(jī)制根據(jù) 業(yè)務(wù)邏輯進(jìn)行改進(jìn)。
連接偶爾出現(xiàn)超時有哪些可能？
主要幾個方面的可能
服務(wù)端確實處理能力有限，cpu idel太低, 無法承受這樣的壓力，或者 是更后端產(chǎn)生問題
accept隊列設(shè)置過小，而連接又特別多，需要增大baklog，建議設(shè)置為128這是我們linux系統(tǒng)默認(rèn)的最大值 由/proc/sys/net/core/somaxconn決定,可以通過修改這個值來增大(由于很多書上這個地方設(shè)置為5,那個其實是4.2BSD支 持的最大值, 而不是現(xiàn)在的系統(tǒng), 不少程序中都直接寫5了,其實可以更大, 不過超過128還是按照128來算)
程序邏輯問題導(dǎo)致accept處理不過來, 導(dǎo)致連接隊列中的連接不斷增多直到把accept隊列撐爆, 像簡單的線程模型(每個線程一個accept), 線程被其他IO一類耗時操作handle,導(dǎo)致accept隊列被撐爆, 這個時候默認(rèn)的邏輯是服務(wù)端丟棄數(shù)據(jù)包，導(dǎo)致client端出現(xiàn)超時，但是可以通過打開/proc/sys/net/ipv4/tcp_abort_on_overflow開關(guān)讓服務(wù)端立刻返回失敗
當(dāng)讀超時的時候(或者其他異常), 我們都會把連接關(guān)閉,進(jìn)行重新連接,這樣的行為如果很多,也可能造成accept處理不過來
異常情況下,設(shè)置了SO_LINGER造成連接的ack包被丟失, 雖然情況極少,但大壓力下還是有存在的.當(dāng)然還是有可能是由于網(wǎng)絡(luò)異?；蛘呖鐧C(jī)房耗時特別多產(chǎn)生的, 這些就不是用戶態(tài)程序可以控制的。
另外還有發(fā)現(xiàn)有些程序采用epoll的單線模式, 但是IO并沒有異步化,而是阻塞IO,導(dǎo)致了處理不及時.網(wǎng)絡(luò)編程常見問題總結(jié) 串講(七)
listen的時候的backlog有什么影響？
backlog代表連接的隊列, 這里對于內(nèi)核中其實會維護(hù)2個隊列
未完成隊列, 這個是服務(wù)器端接收到連接請求后會先放到這里(第一次握手)這個時候端口會處于SYN_RCVD狀態(tài)
已完成隊列，完成三次握手的連接會放到這里，這個時候才是連接建立
在我們 的linux環(huán)境中backlog 一般是被定義為已完成隊列的長度，為完成隊列一般是按照以完成隊列長度的一半來取，backlog為5，那么已完成隊列為5，未完成隊列為3，總共是8個。如果這里的8個都被占滿了，那么后面的連接就會失敗，這里的行為可以由 /proc/sys/net/ipv4/tcp_abort_on_overflow 參數(shù)控制，這個參數(shù)打開后隊列滿了會發(fā)送RST包給client端，client端會看到Connection reset by peer的錯誤(線上部分內(nèi)核打開了這個參數(shù)), 如果是關(guān)閉的話, 服務(wù)端會丟棄這次握手, 需要等待TCP的自動重連, 這個時間一般比較長, 默認(rèn)情況下第一次需要3秒鐘, 由于我們的連接超時一般都是很小的, client采用ullib庫中的超時連接函數(shù), 那么會發(fā)現(xiàn)這個時候連接超時了。
長連接和短連接混用是否會有問題？
雖然這種方式并不合適，但嚴(yán)格來說如果程序中做好相關(guān)的守護(hù)操作(包括一些情況下系統(tǒng)參數(shù)的調(diào)整)是不會出現(xiàn)問 題，基本來說在長短連接混用情況下出現(xiàn)的問題都是由于我們的程序存在不同程度上的缺陷造成的．
可能出現(xiàn)的問題：
只要有一端采用了短連接，那么就可以認(rèn)為總體是短連接模式。
服務(wù)端長連接，客戶端短連接
客戶端主動關(guān) 閉，服務(wù)端需要接收到close的FIN包，read返回0 后才知道客戶端已經(jīng)被關(guān)閉。在這一段時間內(nèi)其實服務(wù)端多維護(hù)了一個沒有必要連接的狀態(tài)。在同步模式(pendingpool，ub-xpool, ub-cpool, ub-epool)中由于read是在工作線程中，這個連接相當(dāng)于線程多做了一次處理，浪費了系統(tǒng)資源。如果是IO異步模式(ub/apool或者使用 ependingpool讀回調(diào)）則可以馬上發(fā)現(xiàn)，不需要再讓工作線程進(jìn)行處理
服務(wù)端如果采用普通線程模型(ub-xpool)那么在異常情況下FIN包如果沒有及時到達(dá)，在這一小段時間內(nèi)這個處理線程不能處理業(yè)務(wù)邏輯。如果出現(xiàn)問題的地方比較多這個時候可能會有連鎖反應(yīng)短時間內(nèi)不能相應(yīng)。
服務(wù)端為長連接，對于服務(wù)提 供者來說可能早期測試也是采用長連接來進(jìn)行測試，這個時候accept的baklog可能設(shè)置的很小，也不會出現(xiàn)問題。但是一旦被大量短連接服務(wù)訪問就可能出現(xiàn)問題。所以建議listen的時候baklog都設(shè)置為128, 我們現(xiàn)在的系統(tǒng)支持這么大的baklog沒有什么問題。
每次總是客戶端主動斷開，這導(dǎo)致客戶端出現(xiàn)了TIME_WIAT的狀態(tài)，在沒有設(shè)置SO_LINGER或者改變系統(tǒng)參數(shù)的情況下，比較容易出現(xiàn)客戶端端口不夠用的情況。
服務(wù)端短連接，客戶端長連接這個時候的問 題相對比較少，但是如果客戶端在發(fā)送數(shù)據(jù)前（或者收完數(shù)據(jù)后）沒有對臟數(shù)據(jù)進(jìn)行檢查，在寫的時候都會出現(xiàn)大量寫錯誤或者讀錯誤，做一次無用的操作，浪費系統(tǒng)資源 一般的建議是采用長連接還是短連接，兩端保持一致，但采用配置的方式并不合適，這個需要在上線的時候檢查這些問題。比較好的方式是把采用長連接還是短連接放到數(shù)據(jù)包頭部中?？蛻舳税l(fā)送的時候標(biāo)記自己是采用 短連接還是長連接，服務(wù)端接收到后按照客戶端的情況采取相應(yīng)的措施，并且告知客戶端。特別的如果服務(wù)端不支持長連接，也可以告知客戶端，服務(wù)采用了短連 接
要注意的是，如果采用了一些框架或者庫，在read到0的情況下可能會多打日志，這個對性能的影響可能會比較大。
網(wǎng)絡(luò)編程常見問題總結(jié) 串講(八)
select, epoll使用上的注意
select, epoll實現(xiàn)上的區(qū)別可以參考, 本質(zhì)上來說 select, poll的實現(xiàn)是一樣的，epoll由于內(nèi)部采用了樹的結(jié)構(gòu)來維護(hù)句柄數(shù)，并且使用了通知機(jī)制，省去了輪詢的過程，在對于需要大量連接的情況下在CPU上會有一定的優(yōu)勢．
select默認(rèn)情況下可以支持句柄數(shù) 是1024, 這個可以看/usr/include/bits/typesizes.h 中的__FD_SETSIZE，在我們的編譯機(jī)（不是開發(fā)機(jī)，是SCMPF平臺的機(jī)器）這個值已經(jīng)被修改為51200, 如果select在處理fd超過1024的情況下出現(xiàn)問題可用檢查一下編譯程序的機(jī)器上__FD_SETSIZE是否正確．
epoll在句柄數(shù)的限制沒有像select那樣需要通過改變系統(tǒng)環(huán)境中的宏來實現(xiàn)對更多句柄的支持
另外我們發(fā)現(xiàn)有些程序在使用epoll的時候打開了邊緣觸發(fā)模式(EPOLLET), 采用邊緣觸發(fā)其實是存在風(fēng)險的,在代碼中需要很小心,避免由于連接兩次數(shù)據(jù)到達(dá),而被只讀出一部分的數(shù)據(jù).EPOLLET的本意是在數(shù)據(jù)情況發(fā)生變化的時候激活(比如不可讀進(jìn)入可讀狀態(tài)), 但問題是這個時候如果在一次處理完畢后不能保證fd已經(jīng)進(jìn)入了不可讀狀態(tài)(一般來說是讀到EAGIN的情況), 后續(xù)可能就一直不會被激活.一般情況下建議使用EPOLLET模式.一個最典型的問題就是監(jiān)聽的句柄被設(shè)置為EPOLLET, 當(dāng)同時多個連接建立的時候, 我們只accept出一個連接進(jìn)行處理, 這樣就可能導(dǎo)致后來的連接不能被及時處理,要等到下一次連接才會被激活.小提示: ullib 中常用的ul_sreado_ms_ex，ul_swriteo_ms_ex內(nèi)部是采用select的機(jī)制，即使是在scmpf平臺上編譯出來也還是受到 51200的限制，可用ul_sreado_ms_ex2,和ul_swriteo_ms_ex2這個兩個接口來規(guī)避這個問題，他們內(nèi)部不是采用 select的方式來實現(xiàn)超時控制的(需要ullib 3.1.22以后版本)
一個進(jìn)程的socket句柄數(shù)只能是1024嗎？
答案是否定的，一臺機(jī)器上可以使用的socket句柄數(shù)是由系統(tǒng)參數(shù) /proc/sys/fs/file-max 來決定的．這里的1024只不 過是系統(tǒng)對于一個進(jìn)程socket的限制，我們完全可以采用ulimit的參數(shù)把這個值增大，不過增大需要采用root權(quán)限，這個不是每個工程師都可以采 用的．所以 在公司內(nèi)采用了一個limit的程序，我們的所有的機(jī)器上都有預(yù)裝這個程序，這個程序已經(jīng)通過了提權(quán)可以以root的身份設(shè)置ulimit的 結(jié)果．使用的時候 limit./myprogram 進(jìn)行啟動即可，默認(rèn)是可以支持51200個句柄，采用limit-n num 可以設(shè)置實際的句柄數(shù).如果還需要更多的連接就需要用ulimit進(jìn)行專門的操作.另外就是對于內(nèi)核中還有一個宏NR_OPEN會限制fd的做大個數(shù)，目前這個值是1024*1024
小提示： linux系統(tǒng)中socket句柄和文件句柄是不區(qū)分的，如果文件句柄＋socket句柄的個數(shù)超過1024同樣也會出問題，這個時候也需要limit提高句柄數(shù)．
ulimit對于非root權(quán)限的帳戶而言只能往小的值去設(shè)置, 在終端上的設(shè)置的結(jié)果一般是針對本次shell的, 要還原退出終端重新進(jìn)入就可以了。
用limit方式啟動，程序讀寫的時候出core?
這個又是另外一個問題，前面已經(jīng)提到了在網(wǎng)絡(luò)程序中對于超時的控制是往往會采用select或者poll的方式．select的時候?qū)τ谥С值腇D其 實是有上限的，可以看/usr/inclue/sys/select.h中對于fd_set的聲明，其實一個__FD_SETSIZE /(8*sizeof(long))的long數(shù)組，在默認(rèn)情況下__FD_SETSIZE的定義是1024，這個可以看 /usr/include/bits/typesizes.h 中的聲明，如果這個時候這個宏還是1024，那么對于采用select方式實現(xiàn)的讀寫超時控制程序在處理超過1024個句柄的時候就會導(dǎo)致內(nèi)存越界出 core ．我們的程序如果是線下編譯，由于許多開發(fā)機(jī)和測試這個參數(shù)都沒有修改，這個時候就會造成出core，其實不一定出core甚至有些情況下會出現(xiàn)有數(shù)據(jù)但 還是超時的情況． 但對于我們的SCMPF平臺上編譯出來的程序是正常的，SCMPF平臺上這個參數(shù)已經(jīng)進(jìn)行了修改，所以有時會出現(xiàn)QA測試沒問題，RD 自測有問題的情況。
一臺機(jī)器最多可以建立多少連接？
理論上來說這個是可以非常多的，取決于可以使用多少的內(nèi)存．我們的系統(tǒng)一般采用一個四元組來表示一個唯一的連接{客戶端ip, 客戶端端口，服務(wù)端ip, 服務(wù)端端口}(有些地方算上TCP, UDP表示成５元組), 在網(wǎng)絡(luò)連接中對于服務(wù)端采用的一般是bind一個固定的端口，然后監(jiān)聽這個端口，在有連接建立的時候進(jìn)行accept操作，這個時候所有建立的連接都只 用到服務(wù)端的一個端口．對于一個唯一的連接在服務(wù)端ip和 服務(wù)端端口都確定的情況下，同一個ip上的客戶端如果要建立一個連接就需要分別采用不同的端，一臺機(jī)器上的端口是有限，最多65535(一個 unsigned char)個，在系統(tǒng)文件/proc/sys/net/ipv4/ip_local_port_range 中我們一般可以看到32768 61000 的結(jié)果，這里表示這臺機(jī)器可以使用的端口范圍是32768到61000, 也就是說事實上對于客戶端機(jī)器而言可以使用的連接數(shù)還不足3W個，當(dāng)然我們可以調(diào)整這個數(shù)值把可用端口數(shù)增加到6W.但是這個時候?qū)τ诜?wù)端的程序完全不受這個限制因為它都是用一個端口，這個時候服務(wù)端受到是連接句柄數(shù)的限制，在上面對于句柄數(shù)的說明已經(jīng)介紹過了，一個 進(jìn)程可以建立的句柄數(shù)是由/proc/sys/fs/file-max決定上限和ulimit來控制的．所以這個時候服務(wù)端完全可以建立更多的連接，這個 時候的主要問題在于如何維護(hù)和管理這么多的連接，經(jīng)典的一個連接對應(yīng)一個線程的處理方式這個時候已經(jīng)不適用了，需要考慮采用一些異步處理的方式來解決, 畢竟線程數(shù)的影響放在那邊
小提示： 一般的服務(wù)模式都是服務(wù)端一個端口，客戶端使用不同的端口進(jìn)行連接，但是其實我們也是可以把這個過程倒過來，我們客戶端只用一個端但是服務(wù)端確是不同的端 口，客戶端做下面的修改原有的方式 socket分配句柄-> connect 分配的句柄 改為 socket分配句柄->對socket設(shè)置SO_REUSEADDR選項->像服務(wù)端一樣bind某個端口->connect 就可以實現(xiàn)
不過這種應(yīng)用相對比較少，對于像網(wǎng)絡(luò)爬蟲這種情況可能相對會比較適用，只不過6w連接已經(jīng)夠多了，繼續(xù)增加的意義不一定那么大就是了．
對于一個不存在的ip建立連接是超時還是馬上返回？
這個要根據(jù)情況來看，一般情況connect一個不存在的ip地址，發(fā)起連接的服務(wù)需要等待ack的返回，由于ip地址不存在，不會有返回，這個時候會一直等到超時才返回。如 果連接的是一個存在的ip，但是相應(yīng)的端口沒有服務(wù)，這個時候會馬上得到返回，收到一個ECONNREFUSED（Connection refused）的結(jié)果。
但是在我們的網(wǎng)絡(luò)會存在一些有限制的路由器，比如我們一些機(jī)器不允許訪問外網(wǎng)，這個時候如果訪問的ip是一個外網(wǎng)ip(無論是否存在），這個時候也會馬上返回得到一個Network is unreachable的錯誤，不需要等待。
第三篇：網(wǎng)絡(luò)發(fā)票常見問題解決方法
網(wǎng)絡(luò)發(fā)票常見問題解決方法如下：
1.電子發(fā)票的登錄密碼忘記了怎么辦？
財務(wù)負(fù)責(zé)人和代理開票人的密碼忘記了，可以通過system用戶進(jìn)行修改，system用戶和納稅申報登錄密碼忘記了，需到主管國稅局查詢或初始化。
2.點擊“發(fā)票開具”前面的+號圖標(biāo)不出現(xiàn)要開具的發(fā)票？
說明還未購買電子發(fā)票或已經(jīng)購買但電子票號還未更新，需要聯(lián)系主管稅務(wù)局進(jìn)行購票或進(jìn)行購票信息更新。
3.點擊“電子發(fā)票”圖標(biāo)，無法進(jìn)入開票系統(tǒng)？
說明沒有開戶，需聯(lián)系主管稅務(wù)局進(jìn)行電子發(fā)票的開戶。
4.點擊發(fā)票開具后出現(xiàn)“納稅人無該種類發(fā)票本”的提示？
可能是開票人所分配的發(fā)票沒有啟用或未給他分配發(fā)票，需在“發(fā)票本分配設(shè)置”中分配、啟用該本發(fā)票即可。
5.如果出現(xiàn)“有多本發(fā)票被啟用”的提示？
需在“發(fā)票本分配設(shè)置”中停用多余的發(fā)票本（只啟用1本發(fā)票）來解決。
6.打印發(fā)票時提示“Automation 服務(wù)器不能創(chuàng)建對象”不打??？
需要下載“電子發(fā)票打印控件添加注冊表文件”，并運行、重啟電腦后再打印發(fā)票。
7.發(fā)票填寫完畢，點擊“保存/打印”出現(xiàn)“總金額必須小于最大開具金額”的提示？
單張發(fā)票開具的最大金額是在國稅局開戶時核定的（大部分都是依據(jù)萬元版規(guī)格：99999.99元），如超出會有提示的。要調(diào)整限額的請與主管局聯(lián)系。
8.填開發(fā)票時銷貨單位的信息不能修改？
銷貨單位的信息如發(fā)生變化請事先在“企業(yè)信息維護(hù)”中修改。
9.點擊“生成傳遞單”，無法完成此次操作？
生成傳遞單前，需將瀏覽器的阻止彈出窗口功能關(guān)閉或設(shè)置該網(wǎng)址允許彈出，否則無法完成本次操作。
10.誤操作生成了驗舊傳遞單，怎么辦？
傳遞單生成錯誤須到票證中心解鎖，解鎖后的舊傳遞單(狀態(tài)由原來的“已鎖定”變成“已退回”)必須刪除才能重新生成新傳遞單,找到指定的傳遞單，在查看頁面下方有一個【刪除傳遞單】按鈕，點擊后可以繼續(xù)開票或驗舊等操作。
11.發(fā)票開錯或退回怎么處理？
當(dāng)月開具的發(fā)票可以作廢，隔月開具的必須開紅字發(fā)票。作廢時必須是網(wǎng)上電子票號和紙質(zhì)發(fā)票的號碼同時作廢，網(wǎng)上執(zhí)行“發(fā)票作廢”，紙質(zhì)票蓋作廢章。
第四篇：北外網(wǎng)院學(xué)歷教育常見問題
1、北外網(wǎng)院都有哪些專業(yè)？
答：英語、工商管理、會計學(xué)、信息管理與信息技術(shù)、電子商務(wù)、國際經(jīng)濟(jì)與貿(mào)易、金
融學(xué) 共七個專業(yè)。
2、北外網(wǎng)院學(xué)歷教育招生層次？
答：北外網(wǎng)院學(xué)歷教育有高起專、高起本和專升本三個層次。
3、學(xué)習(xí)時間是多長？
答：高起專和專升本是2.5年學(xué)制，最長5年學(xué)習(xí)年限。高起本是5年學(xué)制，最長8 年學(xué)習(xí)年限。學(xué)制是教育部統(tǒng)一的規(guī)定，高起專和專升本最短不得少于兩年半，高起本不得
少于五年。
4、北外網(wǎng)院招生對象？
答：高起專、高起本：持有高中（或相當(dāng)于高中的中專、技校、職高）及以上學(xué)歷畢業(yè)
證書者；
專升本：持有國民教育系列的?？苹?qū)？埔陨袭厴I(yè)證書者。
報讀高起專和高起本的學(xué)生，報讀時年齡需滿18周歲;報讀專升本的學(xué)生，報讀時年齡 需滿21周歲。
5、一年有幾次招生？什么時間開學(xué)？
答：一年分春、秋兩季招生。春季一般在3月開學(xué)，秋季一般在9月開學(xué)。
6、北外網(wǎng)院有入學(xué)測試嗎？是否有免試入學(xué)？
答：除符合免試入學(xué)條件的學(xué)生外，報名學(xué)生必須本人到學(xué)習(xí)中心參加入學(xué)測試。
免試入學(xué)條件（見下表）
免試入學(xué)條件
（凡具備以下條件之一者可申請免試入學(xué)）
□持有國家承認(rèn)的大專及以上畢業(yè)證書者，專業(yè)不限；
高起專 高起本
□持有當(dāng)年高考或成人高考成績，達(dá)到當(dāng)年當(dāng)?shù)馗呖蓟虺扇烁呖间浫》謹(jǐn)?shù)線英語專業(yè)
者；
□持有大學(xué)英語水平考試四級證書（CET4）或四級考試425分以上者； □持有公共英語(PETS)三級或以上證書者； 層次
專業(yè)
□持有劍橋商務(wù)英語證書（BEC）標(biāo)準(zhǔn)級或以上證書者； □持有全國高職高專英語應(yīng)用能力測試（A）級證書者?！醭钟袊页姓J(rèn)的大專及以上畢業(yè)證書者，專業(yè)不限；
經(jīng)管類專業(yè)
□持有當(dāng)年高考或成人高考成績，達(dá)到當(dāng)年當(dāng)?shù)馗呖蓟虺扇烁呖间浫》謹(jǐn)?shù)線者。
（在入學(xué)注冊時年滿28周歲的學(xué)生可免考英語）□持有國家承認(rèn)的英語專業(yè)大專畢業(yè)證書者；
□持有國家承認(rèn)的本科及以上畢業(yè)證書者，專業(yè)不限（同時可學(xué)分互認(rèn)全部公共基礎(chǔ)課，包括免考教育部統(tǒng)考課程）；
英語專業(yè)
專升本
□持有大學(xué)英語水平考試四級證書（CET4）或四級考試425分以上者； □持有公共英語(PETS)三級或以上證書者；
□持有劍橋商務(wù)英語證書（BEC）標(biāo)準(zhǔn)級或以上證書者； □持有全國高職高專英語應(yīng)用能力測試（A）級證書者。
□持有國家承認(rèn)的本科及以上畢業(yè)證書者，專業(yè)不限（同時可學(xué)分互認(rèn)全部公經(jīng)管類專業(yè) 共基礎(chǔ)課，包括免考教育部統(tǒng)考課程）。
（在入學(xué)注冊時年滿40周歲的學(xué)生可免考英語）
7、入學(xué)考試考什么？
答：高起專入學(xué)測試科目：英語、語文
專升本入學(xué)測試科目：大學(xué)英語、大學(xué)語文
考試形式是紙考或機(jī)考，單科考試時間為1小時。
8、入學(xué)考試的分?jǐn)?shù)線是多少？如何知道錄取結(jié)果？
答：入學(xué)考試語文和英語均達(dá)到60分以上為及格。
錄取查詢：憑用戶名和密碼進(jìn)入“北外網(wǎng)院”首頁“學(xué)員登錄”處，選擇“學(xué)歷教育平
臺”登錄，在“錄取查詢”中查詢結(jié)果。
9、學(xué)費是多少？如何交納學(xué)費？
答：學(xué)費＝學(xué)分單價×總學(xué)分
學(xué)生按學(xué)分繳納學(xué)費，新生注冊需繳納第一學(xué)年所有學(xué)分費用（英語專業(yè)各層次第一學(xué)年需繳納32個學(xué)分的費用；經(jīng)管類專業(yè)高起專、高起本第一學(xué)年需繳納32個學(xué)分的費用，專升本需繳納28個學(xué)分的費用）。第二學(xué)年開始可以按學(xué)期繳納學(xué)費。
10、除了學(xué)費以外，還有其他費用嗎，比如報名費、考試費、教材費等？
答：我院除學(xué)費外，不收報名費和考試費，只收取新生照片掃描費。教材是學(xué)生自愿購買，我院不統(tǒng)一收取教材費。
11、通過什么方式繳納學(xué)費？
答：學(xué)生可通過北外網(wǎng)院學(xué)習(xí)的平臺在線繳納學(xué)費，或到學(xué)習(xí)中心現(xiàn)場刷POS機(jī)方式以及到銀行匯款的方式，將學(xué)費直接支付到北外網(wǎng)院。開學(xué)后，我院統(tǒng)一將學(xué)生學(xué)費發(fā)票寄往各學(xué)習(xí)中心，請學(xué)生到學(xué)習(xí)中心領(lǐng)取學(xué)費發(fā)票。
12、如何購買教材？
答：學(xué)生繳納學(xué)費后，學(xué)習(xí)的平臺會產(chǎn)生學(xué)籍號，教材相關(guān)信息便可在平臺查看，學(xué)生可
以在學(xué)習(xí)的平臺上訂購教材，經(jīng)管專業(yè)的學(xué)生也可根據(jù)教材信息在網(wǎng)上／書店購買。
13、如何進(jìn)行學(xué)習(xí)？
答：學(xué)生通過學(xué)習(xí)文字印刷教材、錄音教材、多媒體課件或隨時隨地點播學(xué)習(xí)的平臺上的網(wǎng)絡(luò)課件、輔導(dǎo)資源、單元測試和階段作業(yè)等完成課程學(xué)習(xí)。同時根據(jù)不同專業(yè)，可以選擇以下助學(xué)服務(wù)：當(dāng)?shù)貙W(xué)習(xí)中心的面授輔導(dǎo)、網(wǎng)院總部的在線實時講座和輔導(dǎo)與答疑、在線非實時輔導(dǎo)與答疑，以及線上和線下不定期的助學(xué)活動。
14、課程考試、免修、免考相關(guān)政策
問：課程考試、課程免修、課程免考分別是什么？
答： 課程考試：課程考試由北外網(wǎng)院統(tǒng)一命題，學(xué)生在當(dāng)?shù)貙W(xué)習(xí)中心參加考試。課程
總評成績根據(jù)不同課程的性質(zhì)由形成性考核（作業(yè)、自測）和課程終結(jié)考試組成。
課程免修：持有國家承認(rèn)的本科及以上畢業(yè)證書者，可免修全部公共基礎(chǔ)課，包括免考教育部統(tǒng)考。
課程免考：學(xué)生可憑已修國民教育系列（普通高考、成人高考、自學(xué)考試、網(wǎng)絡(luò)教育）相同課程合格成績單（四年內(nèi)有效），在專業(yè)教學(xué)計劃范圍內(nèi)申請課程免考。通過其它渠道（如會計執(zhí)業(yè)資格考試、計算機(jī)等級考試、英語等級考試等）獲得的成績，凡符合北外網(wǎng)院相關(guān)規(guī)定的，可申請相應(yīng)課程免考。入學(xué)注冊時年滿28周歲的經(jīng)管類專業(yè)高起專、高起本層次的學(xué)生或入學(xué)注冊時年滿40周歲的經(jīng)管類專業(yè)專升本層次的學(xué)生，免考課程計劃中的大學(xué)英語系列課程。
問：經(jīng)管專業(yè)：哪些條件可申請免考北外的英語課程？哪些條件可以免考統(tǒng)考的《大學(xué)英語B》？
答：
一、報名經(jīng)管類專業(yè)的學(xué)生，符合如下條件之一者，可免考統(tǒng)考大學(xué)英語（B），并可免考原課程計劃中的《大學(xué)英語（1）》《大學(xué)英語（2）》及《大學(xué)英語（3》。
1）獲得全國公共英語等級考試（PETS）三級或以上級別的《筆試成績合格證》者。
2）已獲得大學(xué)英語四、六級合格證書者。3）改革后、2006 年1 月1 日前的大學(xué)英語等級考試成績達(dá)到420分者。（參加2006年1月1日后的大學(xué)英語等級考試，其成績不作為免考條件。）
4）獲得省級教育行政部門組織的成人教育學(xué)位英語考試合格證書者。
5）公共外語修學(xué)俄語、日語的學(xué)生取得國家承認(rèn)的俄語（大學(xué)俄語四級）、日語（日本語能力測試四級或以上級別）考試合格證書者。
6）戶籍（以身份證為準(zhǔn)）在少數(shù)民族聚居地區(qū)的少數(shù)民族學(xué)生。
二、經(jīng)管類專業(yè)?？贫螌W(xué)生入學(xué)注冊時年齡滿28周歲者，可免考《大學(xué)英語（1）》。
三、經(jīng)管類專業(yè)本科段學(xué)生入學(xué)注冊時年齡滿40周歲者，可免考《大學(xué)英語（2）》及《大學(xué)英語（3）》。
15、英語專業(yè)有哪些形式可以提高口語？
答：我們提供多種形式幫助學(xué)生提高口語：
1、在課程中指導(dǎo)學(xué)生如何練習(xí)口語并完成口語作業(yè)；
2、定期舉行的面授輔導(dǎo)課上，在輔導(dǎo)教師的統(tǒng)一組織下，學(xué)生進(jìn)行口語操練；
3、不定期舉行網(wǎng)上實時口語輔導(dǎo)，學(xué)生有機(jī)會與北外老師在網(wǎng)上進(jìn)行口語交流；
4、組織互助學(xué)習(xí)小組、英語俱樂部等活動讓學(xué)生以線上或線下等多種形式進(jìn)行口語交流；
5、不定期舉辦線上線下的英語口語學(xué)習(xí)方法講座。
16、學(xué)生可以自行選課嗎？
答：北外網(wǎng)院的課程設(shè)置是根據(jù)在職人士業(yè)余學(xué)習(xí)的特點、按一定進(jìn)度安排好的，所有課程有先行后續(xù)的關(guān)系，學(xué)生須按北外網(wǎng)院教學(xué)計劃中設(shè)置的順序完成課程學(xué)習(xí)。
17、入學(xué)后，每學(xué)期期末考試怎么考？
答：考核方式分為形成性考核（包括每個單元的自測、階段作業(yè)和小論文）和課程終結(jié)考試（紙筆考試）相結(jié)合的方式。具體考核方式和每種方式所占比例根據(jù)專業(yè)和課程性質(zhì)的不同來確定，在學(xué)習(xí)每個課程前，都會有“開篇單元”，對課程的內(nèi)容、目標(biāo)和考核方式做具體的說明，而且附有樣題。同時，考前會安排網(wǎng)上輔導(dǎo)課，并發(fā)布復(fù)習(xí)資料。
18、期末考試什么時候進(jìn)行？
答：期末考試每年共進(jìn)行兩次，每學(xué)期期末舉行一次。一般情況下會安排在一月份和七
月份。
19、如果有的課程不及格，能夠補考嗎？補考還不及格應(yīng)該怎么辦？
答：每門課程有一次補考機(jī)會。如果補考還不及格，須申請重新學(xué)習(xí)該門課程。
20、北外網(wǎng)院的學(xué)生可以考專業(yè)英語四級、八級嗎？
答：專業(yè)四、八級是對全日制英語專業(yè)學(xué)生的一種英語測試。北外網(wǎng)院是面向在職人士的遠(yuǎn)程教育，教學(xué)理念和教材設(shè)計與傳統(tǒng)全日制的校園教育完全不同。北外網(wǎng)院培養(yǎng)的是用英語做工具的職業(yè)人才，而不是專門研究英語文學(xué)或語言學(xué)的科研人才，所以，北外網(wǎng)院不組織學(xué)生參加專業(yè)四、八級考試。
21、本科畢業(yè)生申請學(xué)士學(xué)位的條件？
是否參加成人英語學(xué)位統(tǒng)考
學(xué)位英語統(tǒng)考
互認(rèn) 專業(yè)名稱 獲得學(xué)士學(xué)位基本要求
1、修滿規(guī)定學(xué)分，達(dá)到畢業(yè)要求；
英語專業(yè)
2、六門學(xué)位課程總評平均成績達(dá)到70分及以上；
3、通過“項目設(shè)計與論文寫作”課程（通過寫作與答辯）。
1、修滿規(guī)定學(xué)分，達(dá)到畢業(yè)要求；
經(jīng)管類專業(yè)
2、專業(yè)基礎(chǔ)課和專業(yè)課總評平均成績達(dá)到70分及以上；
3、畢業(yè)論文寫作及論文答辯成績均達(dá)到良好及以上。
是 否
全國公共英語等級考試（PETS）三級
22、北外網(wǎng)院頒發(fā)什么樣的畢業(yè)和學(xué)位證書？
答：在規(guī)定學(xué)制內(nèi)修滿學(xué)分者，將獲得北京外國語大學(xué)頒發(fā)的國家承認(rèn)的畢業(yè)證書，由教育部電子注冊并注明“網(wǎng)絡(luò)教育”;本科學(xué)生需通過教育部組織的公共基礎(chǔ)課統(tǒng)一考試。符合國家和北京外國語大學(xué)關(guān)于授予學(xué)位的相關(guān)規(guī)定者將獲得北京外國語大學(xué)頒發(fā)的學(xué)士學(xué)位證書。學(xué)生可登錄北外網(wǎng)院網(wǎng)站首頁查看證書樣式。
23、畢業(yè)后是否可以考研或出國留學(xué)，學(xué)歷國家承認(rèn)嗎？
答：北外網(wǎng)院頒發(fā)的證書是國家承認(rèn)的屬于國民教育系列的證書，畢業(yè)信息在中國高等教育學(xué)生信息網(wǎng)上可查詢。網(wǎng)院畢業(yè)生中已有同學(xué)考取國內(nèi)或國外研究生，沒有接到任何同學(xué)反映在報考中遇到了困難。當(dāng)然，研究生招生的具體規(guī)定，需要同學(xué)在報考時咨詢相關(guān)院校，各個學(xué)校要求上會有差異。
第五篇：院感辦檢查常見問題
院感辦檢查常見問題
存在問題
? 醫(yī)療廢棄物交接無記錄（病房人員、運送人員）原因分析
1、醫(yī)療廢棄物交接不規(guī)范；
2、工作人員責(zé)任心差 整改措施
1、嚴(yán)格醫(yī)療廢棄物交接程序并及時簽字
2、增強工作責(zé)任心 ? 紫外線監(jiān)測記錄不完整 原因分析
1、紫外線消毒監(jiān)測記錄不規(guī)范；
2、更換紫外線燈管不及時 整改措施
1、規(guī)范記錄方法并及時記錄
2、更換紫外線燈管并記錄監(jiān)測強度
? 醫(yī)療廢棄物混放/分類不清 原因分析
1、個別醫(yī)護(hù)人員醫(yī)療廢棄物分類概念不清；
2、個別人員圖方便，隨意放 整改措施
1、全科人員強化醫(yī)療廢棄物分類的學(xué)習(xí)
2、按要求將醫(yī)療廢棄物分類放置落實到實處 ? 業(yè)務(wù)學(xué)習(xí)未按計劃執(zhí)行/未掌握 原因分析
1、病人多，工作忙，忘了學(xué)習(xí)
2、對業(yè)務(wù)學(xué)習(xí)重視不夠、流于形式 整改措施
1、加強對業(yè)務(wù)學(xué)習(xí)重要性的認(rèn)識，2、制定可行的學(xué)習(xí)計劃已達(dá)到良好的學(xué)習(xí)效果 ? 消毒液監(jiān)測記錄不全（酒精等）原因分析
對監(jiān)測記錄重視不夠、工作懈怠 整改措施
要求各班盡到工作職責(zé)，及時記錄監(jiān)測結(jié)果 ?
微生物學(xué)監(jiān)測結(jié)果粘貼不及時
原因分析
對監(jiān)測結(jié)果及時粘貼重視不夠、工作懈怠 整改措施
要求各班盡到工作職責(zé)，及時粘貼監(jiān)測結(jié)果 ? 無菌物品過期 原因分析
無菌觀念差，工作懈怠，責(zé)任心差 加強無菌觀念，增強責(zé)任心。整改措施
每日檢查無菌物品滅菌日期，對過期物品及時進(jìn)行滅菌處理。? 環(huán)境衛(wèi)生差/地面、臺面雜亂 原因分析 責(zé)任心差、工作懈怠，未及時清理。整改措施
增強責(zé)任心、及時清理。? 空氣消毒機(jī)清理不及時 原因分析
院內(nèi)感染重視不夠、責(zé)任分工不清 整改措施
指定責(zé)任人、對空氣消毒機(jī)進(jìn)行定期清理 ? 安爾碘無開啟時間 原因分析
無菌觀念差，對消毒液使用不規(guī)范 整改措施
規(guī)范使用消毒液，注明開啟時間 ? 微生物學(xué)監(jiān)測無菌物品超標(biāo) 原因分析
采樣方法不規(guī)范：未燒瓶口、放置時間過長 整改措施
規(guī)范采樣方法、及時送檢（重新采樣后監(jiān)測結(jié)果合格）?
感染性廢物收集袋無標(biāo)識/包裝方法不正確 原因分析
收集方法不規(guī)范、隨意性強 整改措施 規(guī)范收集方法：及時收集、包裝嚴(yán)實、標(biāo)識清楚、嚴(yán)格交接 ? 換藥室無菌鑷子更換不及時超過4小時 原因分析 無菌觀念差 整改措施
加強無菌觀念，嚴(yán)格執(zhí)行無菌物品使用原則。? 醫(yī)生操作時未戴口罩、帽子、個人防護(hù)不到位 原因分析
無菌觀念差、對個人防護(hù)重要性認(rèn)識不夠 整改措施
加強無菌觀念、嚴(yán)格執(zhí)行無菌操作規(guī)程 ? 換藥室碘酒球罐、酒精罐過期 原因分析
無菌觀念差、對換藥室消毒物品管理不完善 整改措施
加強無菌觀念，完善消毒物品管理、責(zé)任到人 ?
微生物學(xué)監(jiān)測發(fā)現(xiàn)銅綠假單胞菌 原因分析
洗手液裝置使用時間過長、未更換 整改措施
1、一次性使用洗手液，每周更換
2、增加每日通風(fēng)次數(shù)
3、做好地面、物表消毒工作 ? 損傷性廢物容器內(nèi)容物過滿/收集不及時 原因分析
預(yù)想節(jié)省銳器盒、減少開支、未及時收集 整改措施
按規(guī)定要求及時收集廢物 ? 紫外線監(jiān)測記錄方法未改正 原因分析
對紫外線監(jiān)測記錄新方法不清楚 整改措施
重新規(guī)范紫外線監(jiān)測記錄方法并按要求記錄 ? 消毒液監(jiān)測試紙過期 原因分析
對消毒液監(jiān)測重要性重視不夠，整改措施
使用有效試紙并隨時檢查監(jiān)測試紙有效期 ? 無菌鑷子無開啟時間 原因分析
無菌觀念差，未按無菌操作規(guī)程操作
整改措施
加強無菌觀念，嚴(yán)格執(zhí)行無菌操作規(guī)程 ? 用后布類放置不合理 原因分析 無菌觀念差，未按規(guī)定放置各類物品 整改措施
嚴(yán)格換藥室區(qū)域劃分，按要求放置各類物品 ? 治療室用后針頭散落地面 原因分析
工作隨意性強，安全意識差 整改措施
加強安全防范意識，認(rèn)真處理用后針頭 ? 損傷性銳器盒封閉不嚴(yán) 原因分析
損傷性銳器盒使用不規(guī)范 整改措施
規(guī)范損傷性銳器盒使用方法
點擊咨詢 