php小編草莓將為大家介紹如何確保為本機「ping」實作創建的IPv4資料包的正確性。在網路通訊中，使用Ping指令可以測試主機之間的連通性。但是，在實際應用中，我們需要確保所傳送的IPv4封包的正確性，以避免出現錯誤或遺失的情況。為此，我們可以採取一些措施來確保資料包的準確性和完整性，從而確保我們獲得準確的Ping結果。接下來，讓我們一起來了解這些措施。
我一直在從事一個業餘項目，該項目本質上是一個網路故障排除工具。我的目的是加深對網路基礎知識的理解，並熟練使用作業系統提供的故障排除工具。
這是一個 CLI 應用程序，它將獲取主機名稱並嘗試診斷問題（如果有）。計劃是先實作 ping 和 traceroute，然後根據我的舒適程度逐步實現其他工具。
但是，我的 ping 實作並不準確，因為 IPv4 封包格式錯誤。這就是wireshark 必須說的話。
1 0.000000 192.168.0.100 142.250.195.132 ICMP 300 Unknown ICMP (obsolete or malformed?)
這是我實作ping的方法
package ping import ( "encoding/json" "net" "github.com/pkg/errors" ) var ( IcmpProtocolNumber uint8 = 1 IPv4Version uint8 = 4 IPv4IHL uint8 = 5 ICMPHeaderType uint8 = 8 ICMPHeaderSubtype uint8 = 0 ) type NativePinger struct { SourceIP string DestIP string } type ICMPHeader struct { Type uint8 Code uint8 Checksum uint16 } type ICMPPacket struct { Header ICMPHeader Payload interface{} } type IPv4Header struct { SourceIP string DestinationIP string Length uint16 Identification uint16 FlagsAndOffset uint16 Checksum uint16 VersionIHL uint8 DSCPAndECN uint8 TTL uint8 Protocol uint8 } type IPv4Packet struct { Header IPv4Header Payload *ICMPPacket } func (p *NativePinger) createIPv4Packet() (*IPv4Packet, error) { versionIHL := (IPv4Version << 4) | IPv4IHL icmpPacket := &ICMPPacket{ Header: ICMPHeader{ Type: ICMPHeaderType, Code: ICMPHeaderSubtype, }, } ipv4Packet := &IPv4Packet{ Header: IPv4Header{ VersionIHL: versionIHL, DSCPAndECN: 0, Identification: 0, FlagsAndOffset: 0, TTL: 64, Protocol: IcmpProtocolNumber, SourceIP: p.SourceIP, DestinationIP: p.DestIP, }, Payload: icmpPacket, } ipv4Packet.Header.Length = 40 bytes, err := json.Marshal(icmpPacket) if err != nil { return nil, errors.Wrapf(err, "error converting ICMP packet to bytes") } icmpPacket.Header.Checksum = calculateChecksum(bytes) bytes, err = json.Marshal(ipv4Packet) if err != nil { return nil, errors.Wrapf(err, "error converting IPv4 packet to bytes") } ipv4Packet.Header.Checksum = calculateChecksum(bytes) return ipv4Packet, nil } func calculateChecksum(data []byte) uint16 { sum := uint32(0) // creating 16 bit words for i := 0; i < len(data)-1; i++ { word := uint32(data[i])<<8 | uint32(data[i+1]) sum += word } if len(data)%2 == 1 { sum += uint32(data[len(data)-1]) } // adding carry bits with lower 16 bits for (sum >> 16) > 0 { sum = (sum & 0xffff) + (sum >> 16) } // taking one's compliment checksum := ^sum return uint16(checksum) } func (p *NativePinger) ResolveAddress(dest string) error { ips, err := net.LookupIP(dest) if err != nil { return errors.Wrapf(err, "error resolving address of remote host") } for _, ip := range ips { if ipv4 := ip.To4(); ipv4 != nil { p.DestIP = ipv4.String() } } // The destination address does not need to exist as unlike tcp, udp does not require a handshake. // The goal here is to retrieve the outbound IP. Source: https://stackoverflow.com/a/37382208/3728336 // conn, err := net.Dial("udp", "8.8.8.8:80") if err != nil { return errors.Wrapf(err, "error resolving outbound ip address of local machine") } defer conn.Close() p.SourceIP = conn.LocalAddr().(*net.UDPAddr).IP.String() return nil } func (p *NativePinger) Ping(host string) error { if err := p.ResolveAddress(host); err != nil { return errors.Wrapf(err, "error resolving source/destination addresses") } packet, err := p.createIPv4Packet() if err != nil { return errors.Wrapf(err, "error creating IPv4Packet") } conn, err := net.Dial("ip4:icmp", packet.Header.DestinationIP) if err != nil { return errors.Wrapf(err, "error eshtablishing connection with %s", host) } defer conn.Close() bytes, err := json.Marshal(packet) if err != nil { return errors.Wrapf(err, "error converting IPv4 packet into bytes") } _, err = conn.Write(bytes) if err != nil { return errors.Wrapf(err, "error sending ICMP echo request") } buff := make([]byte, 2048) _, err = conn.Read(buff) // The implementation doesn't proceed beyond this point if err != nil { return errors.Wrapf(err, "error receiving ICMP echo response") } return nil } 我不確定資料包的畸形是由單一原因還是多種原因造成的。 我覺得問題出在這兩個地方之一（或兩者？）：
40 位元組（wordsize = 4 位元組）。依照可防止結構體損壞的順序編寫結構體欄位。 我參考這個來源來了解各種類型的大小。// 1 word (4 bytes) type ICMPHeader struct { Type uint8 // 8 bit Code uint8 // 8 bit Checksum uint16 // 16 bit } // 3 words (3*4 = 12 bytes) type ICMPPacket struct { Header ICMPHeader // 1 word Payload interface{} // 2 words } // 7 words (7*4 = 28 bytes) type IPv4Header struct { // Below group takes 4 words (each string takes 2 words) SourceIP string DestinationIP string // Following group takes 2 words (each 16 bits) Length uint16 Identification uint16 FlagsAndOffset uint16 Checksum uint16 // Below group takes 1 word (each takes 8 bits) VersionIHL uint8 DSCPAndECN uint8 TTL uint8 Protocol uint8 } // 10 words (40 bytes) type IPv4Packet struct { Header IPv4Header // 7 words as calculated above Payload ICMPPacket // 3 words as calculated above } 實作中缺少一些部分，例如配置計數、為資料包分配序號等，但在此之前需要修復基本實現，即接收 ICMP ECHO 資料包的回應。很高興知道我在哪裡犯了錯。
謝謝！
考慮到我在評論中得到的建議，我已經更新了程式碼，即修復位元組順序並使用原始位元組作為來源位址、目標位址。然而，僅此並不能解決問題，資料包仍然格式錯誤，因此肯定還有其他問題。
我終於讓它工作了。我應該談談代碼的幾個問題。
正如 Andy 正確指出的那樣，我發送的是 JSON 對象，而不是按網路位元組順序發送原始位元組。這是使用binary.Write(buf, binary.BigEndian, field)修復的
但是，由於此方法僅適用於固定大小的值，因此我必須對每個結構體欄位執行此操作，從而使程式碼重複且有些難看。
我知道將Version和IHL欄位組合在一起以優化記憶體的做法，這就是為什麼我的結構中有這個單一欄位VersionIHL。但是在序列化時，字段值（在本例中為 4 和 5）將被單獨序列化，而我沒有這樣做。相反，我將整個VersionIHL欄位的值轉換為位元組。
結果，我發現自己在位元組流中發送了一個意外的八位元組69，該位元組流來自將4和5組合在一起的0100 0101。
我的 ICMP 結構不包含識別符和序號欄位。Wikipedia上的 ICMP 資料報標頭部分提供的資訊感覺有點通用。但是，我發現RFC 頁面（第 14 頁）上的詳細資訊要多得多富有洞察力。
考慮到 ping 實用程式的序號的重要性，這感覺很奇怪。在實作過程中，我經常發現自己想知道序號在程式碼中的適當位置。直到我偶然發現 RFC 頁面，我才清楚地了解何時何地合併序號。
對於任何可能感興趣的人，這裡是功能代碼我已經整理好了。
以上是如何確保為本機「ping」實作所建立的 IPv4 封包的正確性？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
