協議解析源碼

『壹』 tcp/ip 源碼剖析 怎麼樣

先認清你自己學習的出發點吧, 是應用層面方向還是內核協議棧

應用層面,我不是很了解

內核協議棧個人學習流程大概如下:

首先看TCP/IP卷2，理解2層(MAC地址), 3層(IP, 路由),4層(TCP,UDP,ICMP,IGMP)
這里主要理解的框架,先把網路協議層從下到上(或從上到下)理一遍

然後,建議你看<深入理解linux網路技術內幕> 能看英文版最好

按照那本書的目錄,找找網上的資料
稍微理解下sk_buff和net_device這兩個結構
(不要想著去看懂, 要完全看懂這個結構,會花費比較多的時間,而且還要結合網路子系統中的各個應用)

然後,直接把整本書完整看一遍,不要刻意去扣細節,第1遍看這本書只是為了把網路子系統的內部框架建立起來

看完1遍,肯定有自己的見解了,然後,再根據自己需要的,去扣代碼細節

代碼方面,建議不要找最新的代碼,我看這本書選的2.6.16的,最新代碼的話,和這本書對應不上,不便於理解基礎

<深入理解Linux網路技術內幕> 這本書,除了沒有TCP/UDP的詳細解說,至少我沒發現比他還好的書

『貳』 如何開發自己的HttpServer-NanoHttpd源碼解讀

1.能接受HttpRequest並返回HttpResponse
2.滿足一個Server的基本特徵，能夠長時間運行

關於Http協議一般HttpServer都會聲明支持Http協議的哪些特性，nanohttpd作為一個輕量級的httpserver只實現了最簡單、最常用的功能，不過我們依然可以從中學習很多。

首先看下NanoHttpd類的start函數

[java] view plain
public void start() throws IOException {
myServerSocket = new ServerSocket();
myServerSocket.bind((hostname != null) ? new InetSocketAddress(hostname, myPort) : new InetSocketAddress(myPort));

myThread = new Thread(new Runnable() {
@Override
public void run() {
do {
try {
final Socket finalAccept = myServerSocket.accept();
registerConnection(finalAccept);
finalAccept.setSoTimeout(SOCKET_READ_TIMEOUT);
final InputStream inputStream = finalAccept.getInputStream();
asyncRunner.exec(new Runnable() {
@Override
public void run() {
OutputStream outputStream = null;
try {
outputStream = finalAccept.getOutputStream();
TempFileManager tempFileManager = tempFileManagerFactory.create();
HTTPSession session = new HTTPSession(tempFileManager, inputStream, outputStream, finalAccept.getInetAddress());
while (!finalAccept.isClosed()) {
session.execute();
}
} catch (Exception e) {
// When the socket is closed by the client, we throw our own SocketException
// to break the "keep alive" loop above.
if (!(e instanceof SocketException && "NanoHttpd Shutdown".equals(e.getMessage()))) {
e.printStackTrace();
}
} finally {
safeClose(outputStream);
safeClose(inputStream);
safeClose(finalAccept);
unRegisterConnection(finalAccept);
}
}
});
} catch (IOException e) {
}
} while (!myServerSocket.isClosed());
}
});
myThread.setDaemon(true);
myThread.setName("NanoHttpd Main Listener");
myThread.start();
}
1.創建ServerSocket，bind制定埠

2.創建主線程，主線程負責和client建立連接
3.建立連接後會生成一個runnable對象放入asyncRunner中，asyncRunner.exec會創建一個線程來處理新生成的連接。
4.新線程首先創建了一個HttpSession，然後while(true)的執行httpSession.exec。
這里介紹下HttpSession的概念，HttpSession是java里Session概念的實現，簡單來說一個Session就是一次httpClient->httpServer的連接，當連接close後session就結束了，如果沒結束則session會一直存在。這點從這里的代碼也能看到：如果socket不close或者exec沒有拋出異常（異常有可能是client段斷開連接）session會一直執行exec方法。
一個HttpSession中存儲了一次網路連接中server應該保存的信息，比如：URI，METHOD，PARAMS，HEADERS，COOKIES等。
5.這里accept一個client的socket就創建一個獨立線程的server模型是ThreadServer模型，特點是一個connection就會創建一個thread，是比較簡單、常見的socket server實現。缺點是在同時處理大量連接時線程切換需要消耗大量的資源，如果有興趣可以了解更加高效的NIO實現方式。

當獲得client的socket後自然要開始處理client發送的httprequest。

Http Request Header的parse：

[plain] view plain
// Read the first 8192 bytes.
// The full header should fit in here.
// Apache's default header limit is 8KB.
// Do NOT assume that a single read will get the entire header at once!
byte[] buf = new byte[BUFSIZE];
splitbyte = 0;
rlen = 0;
{
int read = -1;
try {
read = inputStream.read(buf, 0, BUFSIZE);
} catch (Exception e) {
safeClose(inputStream);
safeClose(outputStream);
throw new SocketException("NanoHttpd Shutdown");
}
if (read == -1) {
// socket was been closed
safeClose(inputStream);
safeClose(outputStream);
throw new SocketException("NanoHttpd Shutdown");
}
while (read > 0) {
rlen += read;
splitbyte = findHeaderEnd(buf, rlen);
if (splitbyte > 0)
break;
read = inputStream.read(buf, rlen, BUFSIZE - rlen);
}
}
1.讀取socket數據流的前8192個位元組，因為http協議中頭部最長為8192

2.通過findHeaderEnd函數找到header數據的截止位置，並把位置保存到splitbyte內。

[java] view plain
if (splitbyte < rlen) {
inputStream.unread(buf, splitbyte, rlen - splitbyte);
}

parms = new HashMap<String, String>();
if(null == headers) {
headers = new HashMap<String, String>();

}
1.http協議規定header和body之間使用兩個回車換行分割

1.Http協議第一行是Method URI HTTP_VERSION

2.後面每行都是KEY:VALUE格式的header
3.uri需要經過URIDecode處理後才能使用
4.uri中如果包含？則表示有param，httprequest的param一般表現為:/index.jsp?username=xiaoming&id=2

下面是處理cookie，不過這里cookie的實現較為簡單，所以跳過。之後是serve方法，serve方法提供了用戶自己實現httpserver具體邏輯的很好介面。在NanoHttpd中的serve方法實現了一個默認的簡單處理功能。

[java] view plain

發送response的步驟如下：

1.設置mimeType和Time等內容。
2.創建一個PrintWriter，按照HTTP協議依次開始寫入內容
3.第一行是HTTP的返回碼
4.然後是content-Type
5.然後是Date時間
6.之後是其他的HTTP Header
7.設置Keep-Alive的Header，Keep-Alive是Http1.1的新特性，作用是讓客戶端和伺服器端之間保持一個長鏈接。
8.如果客戶端指定了ChunkedEncoding則分塊發送response，Chunked Encoding是Http1.1的又一新特性。一般在response的body比較大的時候使用，server端會首先發送response的HEADER，然後分塊發送response的body，每個分塊都由chunk length\r\n和chunk data\r\n組成，最後由一個0\r\n結束。

9.如果沒指定ChunkedEncoding則需要指定Content-Length來讓客戶端指定response的body的size，然後再一直寫body直到寫完為止。

『叄』 http協議解析 請求行的信息怎麼提取 c語言源碼

實現步驟：
1）用Wireshark軟體抓包得到test.pcap文件
2）程序：分析pcap文件頭 -> 分析pcap_pkt頭 -> 分析幀頭 -> 分析ip頭 -> 分析tcp頭 -> 分析http信息
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
#include<netinet/in.h>
#include<time.h>
#define BUFSIZE 10240
#define STRSIZE 1024
typedef long bpf_int32;
typedef unsigned long bpf_u_int32;
typedef unsigned short u_short;
typedef unsigned long u_int32;
typedef unsigned short u_int16;
typedef unsigned char u_int8;
//pacp文件頭結構體
struct pcap_file_header
{
bpf_u_int32 magic; /* 0xa1b2c3d4 */
u_short version_major; /* magjor Version 2 */
u_short version_minor; /* magjor Version 4 */
bpf_int32 thiszone; /* gmt to local correction */
bpf_u_int32 sigfigs; /* accuracy of timestamps */
bpf_u_int32 snaplen; /* max length saved portion of each pkt */
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
};
//時間戳
struct time_val
{
long tv_sec; /* seconds 含義同 time_t 對象的值 */
long tv_usec; /* and microseconds */
};
//pcap數據包頭結構體
struct pcap_pkthdr
{
struct time_val ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};
//數據幀頭
typedef struct FramHeader_t
{ //Pcap捕獲的數據幀頭
u_int8 DstMAC[6]; //目的MAC地址
u_int8 SrcMAC[6]; //源MAC地址
u_short FrameType; //幀類型
} FramHeader_t;
//IP數據報頭
typedef struct IPHeader_t
{ //IP數據報頭
u_int8 Ver_HLen; //版本+報頭長度
u_int8 TOS; //服務類型
u_int16 TotalLen; //總長度
u_int16 ID; //標識
u_int16 Flag_Segment; //標志+片偏移
u_int8 TTL; //生存周期
u_int8 Protocol; //協議類型
u_int16 Checksum; //頭部校驗和
u_int32 SrcIP; //源IP地址
u_int32 DstIP; //目的IP地址
} IPHeader_t;
//TCP數據報頭
typedef struct TCPHeader_t
{ //TCP數據報頭
u_int16 SrcPort; //源埠
u_int16 DstPort; //目的埠
u_int32 SeqNO; //序號
u_int32 AckNO; //確認號
u_int8 HeaderLen; //數據報頭的長度(4 bit) + 保留(4 bit)
u_int8 Flags; //標識TCP不同的控制消息
u_int16 Window; //窗口大小
u_int16 Checksum; //校驗和
u_int16 UrgentPointer; //緊急指針
}TCPHeader_t;
//
void match_http(FILE *fp, char *head_str, char *tail_str, char *buf, int total_len); //查找 http 信息函數
//
int main()
{
struct pcap_file_header *file_header;
struct pcap_pkthdr *ptk_header;
IPHeader_t *ip_header;
TCPHeader_t *tcp_header;
FILE *fp, *output;
int pkt_offset, i=0;
int ip_len, http_len, ip_proto;
int src_port, dst_port, tcp_flags;
char buf[BUFSIZE], my_time[STRSIZE];
char src_ip[STRSIZE], dst_ip[STRSIZE];
char host[STRSIZE], uri[BUFSIZE];
//初始化
file_header = (struct pcap_file_header *)malloc(sizeof(struct pcap_file_header));
ptk_header = (struct pcap_pkthdr *)malloc(sizeof(struct pcap_pkthdr));
ip_header = (IPHeader_t *)malloc(sizeof(IPHeader_t));
tcp_header = (TCPHeader_t *)malloc(sizeof(TCPHeader_t));
memset(buf, 0, sizeof(buf));
//
if((fp = fopen(「test.pcap」,」r」)) == NULL)
{
printf(「error: can not open pcap file\n」);
exit(0);
}
if((output = fopen(「output.txt」,」w+」)) == NULL)
{
printf(「error: can not open output file\n」);
exit(0);
}
//開始讀數據包
pkt_offset = 24; //pcap文件頭結構 24個位元組
while(fseek(fp, pkt_offset, SEEK_SET) == 0) //遍歷數據包
{
i++;
//pcap_pkt_header 16 byte
if(fread(ptk_header, 16, 1, fp) != 1) //讀pcap數據包頭結構
{
printf(「\nread end of pcap file\n」);
break;
}
pkt_offset += 16 + ptk_header->caplen; //下一個數據包的偏移值
strftime(my_time, sizeof(my_time), 「%Y-%m-%d %T」, localtime(&(ptk_header->ts.tv_sec))); //獲取時間
// printf(「%d: %s\n」, i, my_time);
//數據幀頭 14位元組
fseek(fp, 14, SEEK_CUR); //忽略數據幀頭
//IP數據報頭 20位元組
if(fread(ip_header, sizeof(IPHeader_t), 1, fp) != 1)
{
printf(「%d: can not read ip_header\n」, i);
break;
}
inet_ntop(AF_INET, (void *)&(ip_header->SrcIP), src_ip, 16);
inet_ntop(AF_INET, (void *)&(ip_header->DstIP), dst_ip, 16);
ip_proto = ip_header->Protocol;
ip_len = ip_header->TotalLen; //IP數據報總長度
// printf(「%d: src=%s\n」, i, src_ip);
if(ip_proto != 0×06) //判斷是否是 TCP 協議
{
continue;
}
//TCP頭 20位元組
if(fread(tcp_header, sizeof(TCPHeader_t), 1, fp) != 1)
{
printf(「%d: can not read ip_header\n」, i);
break;
}
src_port = ntohs(tcp_header->SrcPort);
dst_port = ntohs(tcp_header->DstPort);
tcp_flags = tcp_header->Flags;
// printf(「%d: src=%x\n」, i, tcp_flags);
if(tcp_flags == 0×18) // (PSH, ACK) 3路握手成功後
{
if(dst_port == 80) // HTTP GET請求
{
http_len = ip_len – 40; //http 報文長度
match_http(fp, 「Host: 「, 「\r\n」, host, http_len); //查找 host 值
match_http(fp, 「GET 「, 「HTTP」, uri, http_len); //查找 uri 值
sprintf(buf, 「%d: %s src=%s:%d dst=%s:%d %s%s\r\n」, i, my_time, src_ip, src_port, dst_ip, dst_port, host, uri);
//printf(「%s」, buf);
if(fwrite(buf, strlen(buf), 1, output) != 1)
{
printf(「output file can not write」);
break;
}
}
}
} // end while
fclose(fp);
fclose(output);
return 0;
}
//查找 HTTP 信息
void match_http(FILE *fp, char *head_str, char *tail_str, char *buf, int total_len)
{
int i;
int http_offset;
int head_len, tail_len, val_len;
char head_tmp[STRSIZE], tail_tmp[STRSIZE];
//初始化
memset(head_tmp, 0, sizeof(head_tmp));
memset(tail_tmp, 0, sizeof(tail_tmp));
head_len = strlen(head_str);
tail_len = strlen(tail_str);
//查找 head_str
http_offset = ftell(fp); //記錄下HTTP報文初始文件偏移
while((head_tmp[0] = fgetc(fp)) != EOF) //逐個位元組遍歷
{
if((ftell(fp) – http_offset) > total_len) //遍歷完成
{
sprintf(buf, 「can not find %s \r\n」, head_str);
exit(0);
}
if(head_tmp[0] == *head_str) //匹配到第一個字元
{
for(i=1; i<head_len; i++) //匹配 head_str 的其他字元
{
head_tmp[i]=fgetc(fp);
if(head_tmp[i] != *(head_str+i))
break;
}
if(i == head_len) //匹配 head_str 成功，停止遍歷
break;
}
}
// printf(「head_tmp=%s \n」, head_tmp);
//查找 tail_str
val_len = 0;
while((tail_tmp[0] = fgetc(fp)) != EOF) //遍歷
{
if((ftell(fp) – http_offset) > total_len) //遍歷完成
{
sprintf(buf, 「can not find %s \r\n」, tail_str);
exit(0);
}
buf[val_len++] = tail_tmp[0]; //用buf 存儲 value 直到查找到 tail_str
if(tail_tmp[0] == *tail_str) //匹配到第一個字元
{
for(i=1; i<tail_len; i++) //匹配 head_str 的其他字元
{
tail_tmp[i]=fgetc(fp);
if(tail_tmp[i] != *(tail_str+i))
break;
}
if(i == tail_len) //匹配 head_str 成功，停止遍歷
{
buf[val_len-1] = 0; //清除多餘的一個字元
break;
}
}
}
// printf(「val=%s\n」, buf);
fseek(fp, http_offset, SEEK_SET); //將文件指針 回到初始偏移
}

『肆』 幾種開發者常見的開源軟體協議的分析與介紹

本文主要是針對幾種開發者常見的開源軟體協議的分析與介紹。
Mozilla Public License
MPLLicense，允許免費重發布、免費修改，但要求修改後的代碼版權歸軟體的發起者。這種授權維護了商業軟體的利益，，它要求基於這種軟體得修改無償貢獻版權給該軟體。這樣，圍繞該軟體得所有代碼得版權都集中在發起開發人得手中。但MPL是允許修改，無償使用得。MPL軟體對鏈接沒有要求。
BSD開源協議
BSD開源協議是一個給於使用者很大自由的協議。可以自由的使用，修改源代碼，也可以將修改後的代碼作為開源或者專有軟體再發布。 當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：
1. 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。
2. 如果再發布的只是二進制類庫/軟體，則需要在類庫/軟體的文檔和版權聲明中包含原來代碼中的BSD協議。
3. 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟體發布和銷售，因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。
Apache Licence 2.0
Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布(作為開源或商業軟體)。需要滿足的條件：
1. 需要給代碼的用戶一份Apache Licence
2. 如果你修改了代碼，需要再被修改的文件中說明。
3. 在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
4. 如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可，但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。
GPL
GPL許可證是自由軟體的應用最廣泛的軟體許可證，人們可以修改程式的一個或幾個副本或程式的任何部分，以此形成基於這些程式的衍生作品。必須在修改過的檔案中附有明顯的說明：您修改了此一檔案及任何修改的日期。您必須讓您發布或出版的作品，包括本程式的全部或一部分，或內含本程式的全部或部分所衍生的作品，允許第三方在此許可證條款下使用，並且不得因為此項授權行為而收費。
LGPL
Linux就是採用了GPL。GPL協議和BSD,ApacheLicence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改後和衍生的代碼做為閉源的商業軟體發布和銷售。這也就是為什麼我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商業軟體公司開發的免費軟體了。
GPL協議的主要內容是只要在一個軟體中使用(「使用」指類庫引用，修改後的代碼或者衍生代碼)GPL協議的產品，則該軟體產品必須也採用GPL協議，既必須也是開源和免費。這就是所謂的」傳染性」。GPL協議的產品作為一個單獨的產品使用沒有任何問題，還可以享受免費的優勢。
由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議，對於使用GPL協議的開源代碼，商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似
Public Domain
公共域授權。將軟體授權為公共域，這些軟體包沒有授權協議，任何人都可以隨意使用它。
zlib/libpng
只要不誤傳該軟體的起源並保留原始發布的公告，任何人可以以任何目的使用該軟體，包括商業應用
Artistic許可使作者保持對進一步開發的控制。
MIT
MIT是和BSD一樣寬范的許可協議，作者只想保留版權,而無任何其他了限制。也就是說，你必須在你的發行版里包含原許可協議的聲明，無論你是以二進制發布的還是以源代碼發布的。

『伍』 linux源碼分析

linux的tcp-ip棧代碼的詳細分析

1.數據結構(msghdr,sk_buff,socket,sock,proto_ops,proto)

bsd套接字層,操作的對象是socket,數據存放在msghdr這樣的數據結構：

創建socket需要傳遞family,type,protocol三個參數，創建socket其實就是創建一個socket實例，然後創建一個文件描述符結構，並且互相建立一些關聯，即建立互相連接的指針，並且初始化這些對文件的寫讀操作映射到socket的read，write函數上來。

同時初始化socket的操作函數(proto_ops結構),如果傳入的type參數是STREAM類型，那麼就初始化為SOCKET->ops為inet_stream_ops，如果是DGRAM類型，則SOCKET-ops為inet_dgram_ops。對於inet_stream_ops其實是一個結構體，包含了stream類型的socket操作的一些入口函數，在這些函數里主要做的是對socket進行相關的操作，同時通過調用下面提到的sock中的相關操作完成socket到sock層的傳遞。比如在inet_stream_ops里有個inet_release的操作，這個操作除了釋放socket的類型空間操作外，還通過調用socket連接的sock的close操作，對於stream類型來說，即tcp_close來關閉sock

釋放sock。

創建socket同時還創建sock數據空間，初始化sock,初始化過程主要做的事情是初始化三個隊列，receive_queue(接收到的數據包sk_buff鏈表隊列),send_queue(需要發送數據包的sk_buff鏈表隊列),backlog_queue(主要用於tcp中三次握手成功的那些數據包,自己猜的),根據family、type參數，初始化sock的操作，比如對於family為inet類型的，type為stream類型的，sock->proto初始化為tcp_prot.其中包括stream類型的協議sock操作對應的入口函數。

在一端對socket進行write的過程中，首先會把要write的字元串緩沖區整理成msghdr的數據結構形式(參見linux內核2.4版源代碼分析大全),然後調用sock_sendmsg把msghdr的數據傳送至inet層，對於msghdr結構中數據區中的每個數據包，創建sk_buff結構，填充數據，掛至發送隊列。一層層往下層協議傳遞。一下每層協議不再對數據進行拷貝。而是對sk_buff結構進行操作。

『陸』 tcp/ip協議詳解都是具體的代碼嗎

概括的說TCP/IP協議是（傳輸控制協議/網間協議）TCP/IP 協議集確立了 Internet 的技術基礎。全稱Transmission Control Protocol/Internet Protocol。中譯名為傳輸控制協議/網際網路互聯協議，又名網路通訊協議，是Internet最基本的協議、Internet國際互聯網路的基礎，由網路層的IP協議和傳輸層的TCP協議組成。TCP/IP 定義了電子設備如何連入網際網路，以及數據如何在它們之間傳輸的標准。協議採用了4層的層級結構，每一層都呼叫它的下一層所提供的網路來完成自己的需求。通俗而言：TCP負責發現傳輸的問題，一有問題就發出信號，要求重新傳輸，直到所有數據安全正確地傳輸到目的地。而IP是給網際網路的每一台電腦規定一個地址。
診斷TCP IP協議網路故障時可能會使人灰心喪氣,不過也充滿了樂趣｡傳統的TCP IP協議網路故障我們已經大致了解，但其另一種方法結構化的方法很多人都不太清楚。下面，我們就來看看其故障診斷的方法。
通常，TCP IP協議網路故障的結構化診斷的方法由三個關鍵部分組成:
一、診斷故障措施
（1）驗證有關客戶端和伺服器端的路由選擇的連通性
要使用ping,pathping,tracert,或其它類似的工具,便於在網路層上驗證端到端的TCP IP的連接性;採用數據包嗅探以監視傳輸層會話;使用nslookup,telnet和其它的工具來診斷包括域名解析問題､身份驗證等應用層問題｡
（2）驗證有關客戶端､伺服器和網路架構硬體的物理媒體
檢查電纜,確保網路適配器正確安裝,並進一步查找､驗證可以顯示媒體斷開狀態的網路連接｡
（3）驗證有關客戶端､伺服器､網路架構硬體的TCP IP協議配置
在客戶端上這意味著檢查IP地址､子網掩碼､默認網關､DNS設置等等｡對於網路架構硬體而言,也就是指路由器上的路由表和Internet網關｡
二、幾個方面的因素
標志性信息:客戶端機器上的出錯消息,登錄對話框等等｡
期間:連續的､間斷的,還是偶爾的,何時開始等｡
出現問題的連接類型:物理層､網路層､傳輸層還是應用層?身份驗證還是訪問控制等等｡
其間的網路:線纜(如果不是無線的話)､集線器､交換機､路由器､防火牆､代理伺服器,以及客戶端和伺服器之間的其它網路架構｡
范圍:一個或多個有關的客戶端/伺服器端｡
客戶端:即出現問題的客戶端
伺服器端:客戶無法訪問的伺服器､列印機或其它的網路資源(如互聯網)等｡
環境:可能會影響你的網路的外部情況,如電源的波動､建築物的維護等等｡
三、理解和方法
（2）問一些恰當的問題對故障診斷很關鍵
要學會何時按部就班,何時以跳躍性思維直奔主題是故障診斷藝術的本質所在,這還括充分使用你的左右腦
,即要有充分的想像和縝密的思維｡
（3）踏踏實實地測試,並隔離問題

『柒』 2015最新WebQQ3.0協議解析和易語言實現如何獲取JS加密源代碼

2015最新WebQQ3.0協議解析和易語言實現（一）獲取驗證碼_網路影視
http://cache.content.com/c?m=&p=823fc45385cc43fb08e29f7d5057&newp=&user=&fm=sc&query=2015%D7%EE%D0%C2WebQQ3%2E0%D0%AD%D2%E9%BD%E2%CE%F6%BA%CD%D2%D7%D3%EF%D1%D4%CA%B5%CF%D6%C8%E7%BA%CE%BB%F1%C8%A1JS%BC%D3%C3%DC%D4%B4%B4%FA%C2%EB&qid=a109c1f100005c08&p1=3

『捌』 謝有TCP/IP詳解的代碼有能發我一分嗎

一、分層

1、網路協議通常分不同層次進行開發，每一層分別負責不同的通信功能。

2、TCO/IP通常被認為是一個四層協議系統：

1）、鏈路層，有時候也被稱作數據鏈路層或網路介面層，通常包括操作系統中的設備驅動程序和計算機中對應的網路介面卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理介面細節。

2）、網路層，有時也稱作互聯網層，處理分組在網路中的活動。在TCP/IP協議族中，網路層協議包括IP協議（網際協議），ICMP協議（internet互聯網控制報文協議），以及IGMP協議（internet組管理協議）。

3）、運輸層主要為兩台主機上的應用程序提供端到端的通信。在TCP/IP協議族中，有兩個互不相同的傳輸協議：TCP（傳輸控制協議）和UDP（用戶數據報協議）。

4）、應用層負責處理特定的應用程序細節。

3、在TCP/IP協議族中，網路層IP提供的是一個不可靠的服務，它只是盡可能快地把分組從源節點送到目的節點，不提供任何可靠性的保證。另一方面，TCP在不可靠的IP層上提供一個可靠的運輸層。

二、TCP/IP的分層

1、TCP/IP協議族中不同層次的協議

1）、幀頭和幀尾所標注的數字是典型乙太網首部的長度。

2）、乙太網數據幀的物理特性是其長度必須在46~1500位元組之間。

3）、圖中IP和網路介面層傳送的數據單元應該是分組。分組既可以是一個IP數據報，也可以是IP數據報的一個片。

4）、UDP數據和TCP數據基本一致。唯一不同的是UDP傳送給IP的信息單元稱作UDP數據報，而UDP首部的長度為8位。

5）、由於TCP、UDP、ICMP、IGMP都要向IP傳送數據，因此IP必須在生成的IP首部加入某種標識，以表明數據屬於那一層。IP在首部存入一個長度為8位的數值，稱作協議域。1表示IGMP協議，2表示ICMP協議，6表示TCP協議，17表示UDP協議。

6）、TCP、UDP、網路介面也要在首部加入標識符。

2、當應用程序用TCP傳送數據時，數據被送入協議棧中，然後逐個通過每一層直到被當作一串比特流送入網路。其中每一層對收到的數據都要添加一些首部信息（有時還要添加尾部信息）。

3、TCP傳給IP的數據單元稱作TCP報文段或簡為TCP段，IP傳給網路介面層的數據單元稱作IP數據報。通過乙太網傳輸的比特流稱作數據幀。

六、分用

當目的主機收到一個乙太網數據幀時，數據就開始從協議棧中由低往上升，同時去掉各層協議加上的報文首部。每層協議盒都要去檢查報文首部中的協議標識，以確定接受數據的上層協議。這個過程稱作分用。還有乙太網數據幀的分用過程

七、客戶-伺服器模型

1、伺服器提供的服務分兩種類型：

1）、重復型

2）、並發型

2、重復型伺服器通過以下步驟進行交互：

I、等待一個客戶請求的到來

II、處理客戶請求

III、發送響應給發送請求的客戶

IV、返回第I步

3、並發型伺服器採用以下步驟：

I、等待一個客戶請求的到來

II、啟動一個新的伺服器來處理這個請求

III、返回第I步

4、一般來說，TCP伺服器是並發的，而UDP伺服器是重復的，但也存在一些例外。

八、埠號

1、伺服器一般都是通過知名埠號來識別的。客戶使用臨時設定的埠號。

2、大多數TCP/IP實現給臨時埠分配1024~5000之間的埠號。大於5000的埠號是為其他伺服器預留的。

3、Uinx系統有保留埠號的概念。只有超級用戶特權的進程才允許給它自己分配一個保留埠號。

『玖』 TCP/IP協議詳解學習

這本書我看了好多遍了 但是學習TCP/IP協議不是靠看書就有用的
閱讀代碼是唯一的途徑 看不懂源碼是沒可能理解協議本身的
但是直接去讀Linux TCP/IP的源碼 門檻太高了 不適合初學者 當然如果你智商夠高的話..
我當時花了3個月的時間讀了LWIP的代碼 LWIP是輕量級的TCPIP協議棧 沒有Linux的那麼復雜
有了一定理論基礎 你可以用wireshark去抓一些包來解讀 印證...
最後就是 去做這方面的項目 從中獲得解決具體問題的能力...
以上都搞定了 你可以打電話可獵頭換工作了...

『拾』 tcp ip協議詳解例子代碼是什麼語言 例如：bsdi % arp -a bsdi %telnet avr4 discard ……

這個是UNIX系統的命令，不是什麼特別的語言。