最近在看0-1024熟知埠所對應的內容，然後寫了指令碼對iana資料庫所提供的埠和服務對應的關係進行了歸類，發現如下的埠是值得注意的地方。
就在處理0-1024埠的時候，出現的值得注意的地方列舉如下。
總的來說，有些埠已經加入了對sctp以及dccp的支援。sctp和dccp可以看成分別是對tcp和udp的改進。但是由於目前應用不是很廣，我對此方面了解也不是很多，這裡還是主要看一下tcp和udp的情況。每乙個埠都包含tcp和udp兩種傳輸層的協議，但是該埠的這兩種傳輸層對應的協議名則不一定相同，體現如下。
關於名字的不同之處，rfc6335在第五部分servicenames做了解釋。主要包括三種情況（1）、同乙個服務的擴充套件，例如stun和turn;（2）、歷史遺留問題如http和www；（3）、名字更新，老的名字不符合語法標準，修改為符合語法標準的情況，例如埠774udp名字由acmaint_dbd修改為acmaint-dbd。
埠113，有兩個名字ident和auth，但是作為服務的ident只支援113的tcp埠，而auth則支援tcp和udp。根據rfc6335的描述ident應該是auth 擴充套件服務之類的。
埠456，針對該埠的tcp則是macon-tcp，而udp則是macon-udp。其實我可以認為這個就是macon服務，沒有必要寫成macon-tcp和macon-udp兩種形式，因為別的tcp和udp都支援的協議都沒有這麼做。之所以這麼寫應該是歷史遺留問題。（這個其實也應該發郵件問一問iana的）
埠465，512，513，514，520，623，664，750，773，774,775這些埠的tcp和udp協議的確對應著不同的服務
埠270，271，323，324，716只支援tcp或者udp中的一種
埠757，在iana的資料庫中沒有標註出來，沒有說明該埠是沒有分配，保留還是已經提供了服務。
埠1008，這個埠被標註了兩次，一次是在1001-1009這個埠範圍內，一次是單獨標出來的。不知這個是相關工作人員的有意為之，還是失誤了。截止這邊文章寫完的時候，這個問題還是存在的。（757和1008這兩種情況在最新資料庫中已經被修復了，不得不吐槽iana的工作效率不高啊，從我發郵件開始到反饋一共過了9天，不過他們也愉快的承認了自己的失誤，見下圖）
埠2和3都是compressnet服務；38和256都是rap服務；83和85兩個埠都是對應的mit-ml-dev服務；66和150都是sql服務；570和571都是meter服務。
埠257就由visa等信用卡組織所制定的信用卡支付協議set。
埠445是微軟進行共享檔案等網路服務的埠，即microsoft-ds，很容易被黑客利用。
因為乙個埠的同一種協議對應多個服務名的情況還是較為普遍，就不列出來了。當然還有很多埠沒有分配或者保留的情況也不做說明。
以上就是在處理的時候遇到的一些坑，所謂前人栽樹，後人乘涼，希望對你有幫助。
今日二三事
上午早起去辦租賃備案，辦完了回來啟用了信用卡並稍微摸索了下，中午和室友一起訂烤魚和小龍蝦，吃完都十二點多，午睡未睡著看了一會漫畫和 去書房三點多，買了一杯咖啡，看看一些前端文章，狀態好的情況下還是可以看進去一些英文文件的。晚飯後繼續看，邊看邊跟老弟聊天，他最近要學python，我打算也學一學，順便帶...
生活二三事
今天遭遇了一系列的事情，這些事情用當前的我個人的認知來說算是衰事吧，乙個倒也見怪不怪，但今天的接憧而至的架勢的的確確給我挫折感。然後呢我不得不散了會步，按照平時的狀態我是極其不喜歡乙個人散步的，因為那樣會感覺很孤獨，畢竟大學校園三五成群，兩兩相依的情景隨處可見，總以別人的眼光來看待自己很是累，恩。路...
招聘二三事
今天遇到乙個特別奇葩的面試者，為了爭取面試機會，真的是用盡了方法，鉚足了勁兒，先是質疑筆試題的專業性，然後質疑面試官的水平。不管你問什麼問題，他都想爭辯幾句，明顯已經所答非所問了，在多次友情提示後依然要堅持己見，自說自話。耗盡了我所有的耐心，但出於個人職業道德，還是強忍著內心的焚寂煞氣，面色和悅的給...