ชุดโปรโตคอลอินเทอร์เน็ต

ชุดโปรโตคอลอินเทอร์เน็ตหรือที่เรียกกันทั่วไปว่าTCP/IPเป็นเฟรมเวิร์กสำหรับจัดระเบียบชุดโปรโตคอลการสื่อสารที่ใช้ในอินเทอร์เน็ตและเครือข่ายคอมพิวเตอร์ ที่คล้ายกัน ตามเกณฑ์การทำงาน โปรโตคอลพื้นฐานในชุดคือTransmission Control Protocol (TCP), User Datagram Protocol (UDP) และInternet Protocol (IP) โมเดลเครือข่ายรุ่นแรกๆ เป็นที่รู้จักในชื่อโมเดลกระทรวงกลาโหม ( DoD ) เนื่องจากการวิจัยและพัฒนาได้รับทุนสนับสนุนจากกระทรวง กลาโหมสหรัฐอเมริกาผ่านทางDARPA

ชุดโปรโตคอลอินเทอร์เน็ตให้การสื่อสารข้อมูลแบบ end-to-endโดยระบุว่าข้อมูลควรถูกแพ็กเก็ต ระบุ ส่ง ส่งกำหนดเส้นทางและรับ ข้อมูลอย่างไร ฟังก์ชันนี้ถูกจัดออกเป็นสี่เลเยอร์นามธรรมซึ่งจัดประเภทโปรโตคอลที่เกี่ยวข้องทั้งหมดตามขอบเขตเครือข่ายของแต่ละโปรโตคอล[1] [2]การใช้งานเลเยอร์สำหรับแอปพลิเคชันเฉพาะจะสร้างโปรโตคอลสแต็ก จากต่ำสุดไปสูงสุด เลเยอร์ต่างๆ คือเลเยอร์ลิงก์ซึ่งมีวิธีการสื่อสารสำหรับข้อมูลที่เหลืออยู่ภายในส่วนของเครือข่ายเดียว (ลิงก์) เลเยอร์อินเทอร์เน็ตให้บริการการเชื่อมต่ออินเทอร์เน็ตระหว่างเครือข่ายอิสระ ชั้นการขนส่งการจัดการการสื่อสารระหว่างโฮสต์กับโฮสต์ และเลเยอร์แอปพลิเคชันซึ่งให้การแลกเปลี่ยนข้อมูลระหว่างกระบวนการสำหรับแอปพลิเคชัน

มาตรฐานทางเทคนิคที่เป็นพื้นฐานของชุดอินเทอร์เน็ตโปรโตคอลและโปรโตคอลที่เป็นส่วนประกอบนั้นได้รับการดูแลโดยInternet Engineering Task Force (IETF) ชุดอินเทอร์เน็ตโปรโตคอลมีมาก่อนโมเดล OSIซึ่งเป็นเฟรมเวิร์กอ้างอิงที่ครอบคลุมมากขึ้นสำหรับระบบเครือข่ายทั่วไป

ประวัติศาสตร์

การวิจัยเบื้องต้น

แผนภาพแสดงการเชื่อมต่ออินเทอร์เน็ตครั้งแรก
SRI International Packet Radio Vanใช้สำหรับการส่งสัญญาณผ่านอินเทอร์เน็ต สามทางครั้งแรก

เดิมเรียกว่าDOD Internet Architecture Modelชุดอินเทอร์เน็ตโปรโตคอลมีรากฐานมาจากการวิจัยและพัฒนาที่ได้รับการสนับสนุนจาก Defense Advanced Research Projects Agency ( DARPA ) ในช่วงปลายทศวรรษ 1960 [3]หลังจากที่ DARPA เริ่มบุกเบิกARPANETในปี 1969 สตีฟ คร็อกเกอร์ได้ก่อตั้ง "คณะทำงานด้านเครือข่าย" ซึ่งพัฒนาโปรโตคอลโฮสต์-โฮสต์ นั่นคือNetwork Control Program (NCP) [4]ในช่วงต้นทศวรรษ 1970 DARPA เริ่มทำงานกับเทคโนโลยีการส่งข้อมูลอื่นๆ มากมาย รวมถึงวิทยุแพ็คเก็ตมือถือ บริการดาวเทียมแพ็คเก็ต เครือข่ายท้องถิ่น และเครือข่ายข้อมูลอื่น ๆ ในโดเมนสาธารณะและส่วนตัว ในปี 1972 Bob Kahn เข้าร่วม สำนักงานเทคโนโลยีการประมวลผลข้อมูล DARPA ซึ่งเขาทำงานในทั้งเครือข่ายแพ็คเก็ตดาวเทียมและเครือข่ายแพ็คเก็ตวิทยุภาคพื้นดิน และตระหนักถึงคุณค่าของความสามารถในการสื่อสารข้ามทั้งสองเครือข่าย ในฤดูใบไม้ผลิปี 1973 Vinton Cerfเข้าร่วมกับ Kahn โดยมีเป้าหมายในการออกแบบการสร้างโปรโตคอลครั้งต่อไปสำหรับ ARPANET เพื่อให้สามารถใช้งานอินเทอร์เน็ต ได้ [5] [6]พวกเขาดึงประสบการณ์จากชุมชนวิจัย ARPANET, International Network Working Groupซึ่ง Cerf เป็นประธาน และนักวิจัยจากXerox PARC [7] [8] [9]

ในฤดูร้อนปี 1973 Kahn และ Cerf ได้ทำการปฏิรูปพื้นฐาน ซึ่งความแตกต่างระหว่างโปรโตคอลเครือข่ายท้องถิ่นถูกซ่อนไว้โดยใช้โปรโตคอลอินเทอร์เน็ต ทั่วไป และแทนที่จะให้เครือข่ายรับผิดชอบด้านความน่าเชื่อถือ เช่นเดียวกับในโปรโตคอล ARPANET ที่มีอยู่ ฟังก์ชันนี้ถูกมอบหมายให้กับโฮสต์ Cerf ให้เครดิตLouis PouzinและHubert Zimmermannผู้ออกแบบ เครือข่าย CYCLADESที่มีอิทธิพลสำคัญต่อการออกแบบนี้[10] [11]โปรโตคอลใหม่ถูกนำมาใช้เป็นโปรแกรมควบคุมการส่งสัญญาณในปี 1974 โดย Cerf, Yogen Dalalและ Carl Sunshine [12]

เริ่มแรก โปรแกรมควบคุมการส่งสัญญาณ ( Internet Protocolไม่ได้มีอยู่ในโปรโตคอลแยกต่างหาก) ให้ บริการ สตรีมไบต์ที่เชื่อถือได้แก่ผู้ใช้เท่านั้น ไม่ใช่ดาตาแกรม[13]เมื่อประสบการณ์เกี่ยวกับโปรโตคอลเพิ่มมากขึ้น ผู้ทำงานร่วมกันแนะนำให้แบ่งการทำงานออกเป็นเลเยอร์ของโปรโตคอลที่แตกต่างกัน ทำให้ผู้ใช้สามารถเข้าถึงบริการดาต้าแกรมได้โดยตรง ผู้สนับสนุน ได้แก่Danny Cohenซึ่งจำเป็นสำหรับ การทำงาน ด้านเสียงแบบแพ็คเก็ต ; Jonathan Postel จาก สถาบันวิทยาศาสตร์สารสนเทศแห่งมหาวิทยาลัยเซาเทิร์นแคลิฟอร์เนียซึ่งเป็นบรรณาธิการคำขอความคิดเห็น (RFCs) ซึ่งเป็นชุดเอกสารทางเทคนิคและเชิงกลยุทธ์ที่มีทั้งเอกสารและตัวเร่งการพัฒนาอินเทอร์เน็ต[14]และBob Metcalfeและ Yogen Dalal ที่ Xerox PARC [15] [16] Postel ระบุว่า "เรากำลังทำผิดพลาดในการออกแบบโปรโตคอลอินเทอร์เน็ตของเราโดยละเมิดหลักการของการแบ่งชั้น" [17]การห่อหุ้มกลไกต่างๆ มีวัตถุประสงค์เพื่อสร้างสภาพแวดล้อมที่ชั้นบนสามารถเข้าถึงเฉพาะสิ่งที่จำเป็นจากชั้นล่างเท่านั้น การออกแบบเสาหินจะไม่ยืดหยุ่นและนำไปสู่ปัญหาด้านความสามารถในการขยายขนาด ใน TCP เวอร์ชัน 3 ซึ่งเขียนขึ้นในปี 1978 Cerf, Cohen และ Postel ได้แยกโปรแกรมควบคุมการส่งสัญญาณออกเป็นสองโปรโตคอลที่แตกต่างกันInternet Protocolเป็นเลเยอร์ไร้การเชื่อมต่อ และTransmission Control Protocolเป็นบริการที่เน้นการเชื่อมต่อที่ เชื่อถือ ได้[nb 1] [18]

การออกแบบเครือข่ายรวมถึงการรับรู้ว่าควรจัดให้มีเฉพาะฟังก์ชันการส่งและกำหนดเส้นทางการรับส่งข้อมูลระหว่างโหนดปลายสุดอย่างมีประสิทธิภาพ และความฉลาดอื่นๆ ทั้งหมดควรอยู่ที่ขอบของเครือข่ายในโหนดปลายสุด การออกแบบนี้เรียกว่าหลักการแบบครบวงจร การใช้การออกแบบนี้ ทำให้สามารถเชื่อมต่อเครือข่ายอื่นๆ กับ ARPANET ที่ใช้หลักการเดียวกันได้ โดยไม่คำนึงถึงลักษณะเฉพาะอื่นๆ ในท้องถิ่น ดังนั้นจึงช่วยแก้ปัญหาการทำงานทางอินเทอร์เน็ตเบื้องต้นของ Kahn สำนวนที่ได้รับความนิยมคือ TCP/IP ซึ่งเป็นผลงานของ Cerf และ Kahn สามารถวิ่งทับ "กระป๋องดีบุกสองกระป๋องและเชือกหนึ่งเส้น" [ ต้องการอ้างอิง ]หลายปีต่อมา เป็นเรื่องตลก ข้อกำหนดโปรโตคอลอย่างเป็นทางการ ของ IP over Avian Carriersถูกสร้างขึ้นและทดสอบได้สำเร็จ

DARPA ทำสัญญากับBBN Technologies , Stanford UniversityและUniversity College Londonเพื่อพัฒนาโปรโตคอลเวอร์ชันปฏิบัติการบนแพลตฟอร์มฮาร์ดแวร์หลายตัวในระหว่างการพัฒนาโปรโตคอล หมายเลขเวอร์ชันของชั้นการกำหนดเส้นทางแพ็คเก็ตได้ก้าวหน้าจากเวอร์ชัน 1 ไปเป็นเวอร์ชัน 4 ซึ่งเวอร์ชันหลังได้รับการติดตั้งใน ARPANET ในปี พ.ศ. 2526 กลายเป็นที่รู้จักในชื่อInternet Protocol เวอร์ชัน 4 (IPv4) เป็นโปรโตคอล ที่ยังคงใช้อยู่ในอินเทอร์เน็ต ควบคู่ไปกับผู้สืบทอดปัจจุบันคือInternet Protocol เวอร์ชัน 6 (IPv6)

การนำไปใช้ตั้งแต่เนิ่นๆ

ในปี 1975 การทดสอบการสื่อสาร IP สองเครือข่ายได้ดำเนินการระหว่าง Stanford และ University College London ในเดือนพฤศจิกายน พ.ศ. 2520 มีการทดสอบ IP สามเครือข่ายระหว่างไซต์ต่างๆ ในสหรัฐอเมริกา สหราชอาณาจักรและนอร์เวย์ต้นแบบทรัพย์สินทางปัญญาอื่นๆ อีกหลายตัวได้รับการพัฒนาในศูนย์วิจัยหลายแห่งระหว่างปี 1978 ถึง 1983

คอมพิวเตอร์ที่เรียกว่าเราเตอร์นั้นมีอินเทอร์เฟซให้กับแต่ละเครือข่าย มันส่งต่อแพ็คเก็ตเครือข่ายไปมาระหว่างพวกเขาเดิมทีเราเตอร์ถูกเรียกว่าเกตเวย์แต่คำนี้เปลี่ยนไปเพื่อหลีกเลี่ยงความสับสนกับเกตเวย์ประเภท อื่น [21]

การรับเป็นบุตรบุญธรรม

ในเดือนมีนาคม พ.ศ. 2525 กระทรวงกลาโหมสหรัฐฯ ได้ประกาศให้ TCP/IP เป็นมาตรฐานสำหรับเครือข่ายคอมพิวเตอร์ทางการทหารทั้งหมด[22] [23]ในปีเดียวกันนั้นNORSAR / NDREและกลุ่มวิจัยของPeter Kirstein ที่ University College Londonได้นำระเบียบการนี้มาใช้การโยกย้ายของ ARPANET จากNCP ไป ยัง TCP/IP เสร็จสิ้นอย่างเป็นทางการในวันที่ 1 มกราคม พ.ศ. 2526 เมื่อมีการเปิดใช้งานโปรโตคอลใหม่อย่างถาวร[22] [25]

ในปี 1985 คณะกรรมการที่ปรึกษาอินเทอร์เน็ต (ต่อมาคือInternet Architecture Board ) ได้จัดเวิร์กช็อป TCP/IP เป็นเวลาสามวันสำหรับอุตสาหกรรมคอมพิวเตอร์ โดยมีตัวแทนผู้จำหน่าย 250 รายเข้าร่วม เพื่อส่งเสริมโปรโตคอลและนำไปสู่การนำไปใช้ในเชิงพาณิชย์เพิ่มมากขึ้น ในปี 1985 การประชุม Interop ครั้งแรก มุ่งเน้นไปที่การทำงานร่วมกันของเครือข่ายโดยการใช้ TCP/IP ในวงกว้างมากขึ้น การประชุมนี้ก่อตั้งโดย Dan Lynch นักกิจกรรมทางอินเทอร์เน็ตในยุคแรก ตั้งแต่แรกเริ่มมีบริษัทขนาดใหญ่อย่าง IBM และ DEC เข้าร่วมการประชุม[26]

IBM, AT&T และ DEC เป็นบริษัทใหญ่กลุ่มแรกๆ ที่ใช้ TCP/IP แม้ว่าจะมีโปรโตคอลที่เป็นกรรมสิทธิ์ ของคู่แข่ง ก็ตาม ใน IBM ตั้งแต่ปี 1984 กลุ่มของBarry Appelman ได้ทำการพัฒนา TCP/IP พวกเขาสำรวจการเมืององค์กรเพื่อรับกระแสผลิตภัณฑ์ TCP/IP สำหรับระบบ IBM ต่างๆ รวมถึงMVS , VMและOS/ 2 ในเวลาเดียวกัน บริษัทขนาดเล็กหลายแห่ง เช่นFTP SoftwareและWollongong Groupเริ่มเสนอ TCP/IP stacks สำหรับDOSและMicrosoft Windows [27] VM/CMS TCP/IP stack แรกมาจากมหาวิทยาลัยวิสคอนซิน[28]

สแต็ก TCP/IP ในยุคแรกๆ บางส่วนถูกเขียนโดยโปรแกรมเมอร์เพียงไม่กี่คนโดยลำพัง Jay Elinsky และ Oleg Vishnepolsky จาก IBM Research เขียน TCP/IP stacks สำหรับ VM/CMS และ OS/2 ตามลำดับในปี 1984 Donald Gillies ที่ MIT ได้เขียนTCP multi-connection ntcpซึ่งทำงานบนเลเยอร์ IP/PacketDriver ที่ดูแลโดย John Romkey ที่ MIT ในปี 1983–84 Romkey ใช้ประโยชน์จาก TCP นี้ในปี 1986 เมื่อซอฟต์แวร์ FTP ก่อตั้งขึ้น[29] [30]เริ่มต้นในปี 1985, Phil Karn ได้สร้างแอปพลิเคชั่น TCP แบบหลายการเชื่อมต่อสำหรับระบบวิทยุแฮม (KA9Q TCP) [31]

การแพร่กระจายของ TCP/IP เพิ่มมากขึ้นในเดือนมิถุนายน พ.ศ. 2532 เมื่อมหาวิทยาลัยแคลิฟอร์เนีย เบิร์กลีย์ตกลงที่จะวางรหัส TCP/IP ที่พัฒนาขึ้นสำหรับBSD UNIXให้เป็นสาธารณสมบัติ ผู้จัดจำหน่ายองค์กรต่างๆ รวมถึง IBM รวมโค้ดนี้ไว้ในซอฟต์แวร์ TCP/IP เชิงพาณิชย์ Microsoft เปิดตัวสแต็ก TCP/IP ดั้งเดิมใน Windows 95 เหตุการณ์นี้ช่วยประสานการครอบงำของ TCP/IP เหนือโปรโตคอลอื่น ๆ บนเครือข่ายที่ใช้ Microsoft ซึ่งรวมถึงSystems Network Architecture (SNA) ของ IBM และบนแพลตฟอร์มอื่น ๆ เช่นDigital Equipment Corporation DECnet , การเชื่อมต่อระบบเปิด (OSI) และระบบเครือข่าย Xerox (XNS)

อย่างไรก็ตาม ในช่วงปลายทศวรรษ 1980 และต้นทศวรรษ 1990 วิศวกร องค์กร และประเทศต่างๆ ต่างก็แตกแยกกันในประเด็นที่ว่ามาตรฐานใดแบบจำลอง OSI หรือชุดโปรโตคอลอินเทอร์เน็ต จะส่งผลให้เกิดเครือข่ายคอมพิวเตอร์ที่ดีที่สุดและแข็งแกร่งที่สุด[32] [33] [34]

ข้อกำหนดและมาตรฐานอย่างเป็นทางการ

มาตรฐานทางเทคนิคที่เป็นพื้นฐานของชุดอินเทอร์เน็ตโปรโตคอลและโปรโตคอลที่เป็นส่วนประกอบได้ถูกมอบหมายให้กับInternet Engineering Task Force (IETF) [35]

สถาปัตยกรรมที่เป็นลักษณะเฉพาะของชุดอินเทอร์เน็ตโปรโตคอลคือการแบ่งขอบเขตการทำงานอย่างกว้างๆ สำหรับโปรโตคอลที่ประกอบเป็นฟังก์ชันหลัก ข้อกำหนดที่กำหนดของชุดนี้คือ RFC 1122 ซึ่งสรุปเลเยอร์นามธรรมสี่ชั้นอย่าง กว้างๆ [1]สิ่งเหล่านี้ยืนหยัดผ่านการทดสอบของกาลเวลา เนื่องจาก IETF ไม่เคยปรับเปลี่ยนโครงสร้างนี้ เนื่องจากโมเดลของระบบเครือข่ายดังกล่าว ชุดอินเทอร์เน็ตโปรโตคอลจึงมีมาก่อนโมเดล OSI ซึ่งเป็นเฟรมเวิร์กอ้างอิงที่ครอบคลุมมากขึ้นสำหรับระบบเครือข่ายทั่วไป[34]

หลักการทางสถาปัตยกรรมที่สำคัญ

การไหลของข้อมูลเชิงแนวคิดในโทโพโลยีเครือข่ายอย่างง่ายของสองโฮสต์ ( AและB ) เชื่อมต่อกันด้วยลิงก์ระหว่างเราเตอร์ที่เกี่ยวข้อง แอปพลิเคชันบนแต่ละโฮสต์ดำเนินการอ่านและเขียนราวกับว่ากระบวนการเชื่อมต่อกันโดยตรงโดยไปป์ข้อมูลบางประเภท หลังจากสร้างไปป์นี้แล้ว รายละเอียดส่วนใหญ่ของการสื่อสารจะถูกซ่อนจากแต่ละกระบวนการ เนื่องจากหลักการพื้นฐานของการสื่อสารถูกนำมาใช้ในเลเยอร์โปรโตคอลที่ต่ำกว่า ในการเปรียบเทียบ ที่เลเยอร์การขนส่ง การสื่อสารจะปรากฏเป็นแบบโฮสต์ถึงโฮสต์ โดยไม่มีความรู้เกี่ยวกับโครงสร้างข้อมูลแอปพลิเคชันและเราเตอร์ที่เชื่อมต่อ ในขณะที่เลเยอร์การทำงานบนอินเทอร์เน็ต ขอบเขตเครือข่ายแต่ละอันจะถูกสำรวจที่เราเตอร์แต่ละตัว
การห่อหุ้มข้อมูลแอปพลิเคชันจากมากไปน้อยผ่านเลเยอร์ต่างๆ ที่อธิบายไว้ใน RFC 1122

หลักการแบบ end-to-endมีการพัฒนาอยู่ตลอดเวลา การแสดงออกดั้งเดิมทำให้การรักษาสถานะและความฉลาดโดยรวมอยู่ที่ขอบ และสันนิษฐานว่าอินเทอร์เน็ตที่เชื่อมต่อกับขอบนั้นไม่มีสถานะใด และมุ่งเน้นไปที่ความเร็วและความเรียบง่าย ความต้องการในโลกแห่งความเป็นจริงสำหรับไฟร์วอลล์ เครื่องมือแปลที่อยู่เครือข่าย แคชเนื้อหาเว็บ และอื่นๆ บังคับให้มีการเปลี่ยนแปลงในหลักการนี้[36]

หลักการความคงทนระบุว่า: "โดยทั่วไป การใช้งานจะต้องระมัดระวังในพฤติกรรมการส่ง และเสรีนิยมในพฤติกรรมการรับ นั่นคือ จะต้องระมัดระวังในการส่งดาตาแกรมที่มีรูปแบบที่ดี แต่ต้องยอมรับดาตาแกรมใด ๆ ที่สามารถตีความได้ ( เช่นไม่คัดค้านข้อผิดพลาดทางเทคนิคโดยที่ความหมายยังชัดเจน)” [37] "ส่วนที่สองของหลักการเกือบจะมีความสำคัญพอๆ กัน: ซอฟต์แวร์บนโฮสต์อื่นอาจมีข้อบกพร่องซึ่งทำให้ไม่ฉลาดที่จะใช้ประโยชน์จากคุณลักษณะของโปรโตคอลที่ถูกกฎหมายแต่คลุมเครือ" [38]

การห่อหุ้มใช้เพื่อจัดทำโปรโตคอลและบริการที่เป็นนามธรรม การห่อหุ้มมักจะสอดคล้องกับการแบ่งชุดโปรโตคอลออกเป็นเลเยอร์ของฟังก์ชันการทำงานทั่วไป โดยทั่วไป แอปพลิเคชัน (ระดับสูงสุดของโมเดล) จะใช้ชุดโปรโตคอลเพื่อส่งข้อมูลลงไปยังเลเยอร์ต่างๆ ข้อมูลจะถูกสรุปเพิ่มเติมในแต่ละระดับ

เอกสารทางสถาปัตยกรรมยุคแรกRFC  1122 ชื่อHost Requirementsเน้นหลักการทางสถาปัตยกรรมมากกว่าการแบ่งชั้น[39] RFC 1122 มีโครงสร้างในส่วนที่อ้างถึงเลเยอร์ แต่เอกสารอ้างอิงถึงหลักการทางสถาปัตยกรรมอื่นๆ มากมาย และไม่เน้นที่การแบ่งชั้น โดยให้คำจำกัดความโมเดลสี่เลเยอร์อย่างหลวมๆ โดยเลเยอร์ต่างๆ มีชื่อ ไม่ใช่ตัวเลข ดังนี้

  • เลเยอร์แอปพลิเคชันคือขอบเขตที่แอปพลิเคชันหรือกระบวนการสร้างข้อมูลผู้ใช้และสื่อสารข้อมูลนี้ไปยังแอปพลิเคชันอื่นบนโฮสต์อื่นหรือโฮสต์เดียวกัน แอปพลิเคชันใช้ประโยชน์จากบริการที่มอบให้โดยชั้นล่าง โดยเฉพาะเลเยอร์การขนส่งซึ่งให้ท่อที่เชื่อถือได้หรือไม่น่าเชื่อถือ กับกระบวนการอื่น ๆ พันธมิตรด้านการสื่อสารมีลักษณะเฉพาะด้วยสถาปัตยกรรมแอปพลิเคชัน เช่นโมเดลไคลเอ็นต์-เซิร์ฟเวอร์และเครือข่ายแบบเพียร์ทูเพียร์นี่คือเลเยอร์ที่โปรโตคอลแอปพลิเคชันทั้งหมดทำงาน เช่น SMTP, FTP, SSH, HTTP กระบวนการต่างๆ ได้รับการแก้ไขผ่านทางพอร์ตซึ่งเป็นตัวแทนของบริการ เป็นหลัก
  • เลเยอร์การขนส่งทำการสื่อสารระหว่างโฮสต์กับโฮสต์บนเครือข่ายท้องถิ่นหรือเครือข่ายระยะไกลที่แยกจากกันโดยเราเตอร์[40]เป็นช่องทางสำหรับความต้องการด้านการสื่อสารของแอปพลิเคชัน UDP เป็นโปรโตคอลการขนส่งเลเยอร์พื้นฐาน ซึ่งให้บริการดาตาแกรมแบบไร้การเชื่อมต่อ ที่ไม่น่าเชื่อถือ Transmission Control Protocol ให้การควบคุมการไหล การสร้างการเชื่อมต่อ และการส่งข้อมูลที่เชื่อถือได้
  • เลเยอร์อินเทอร์เน็ตจะแลกเปลี่ยนดาตาแกรมข้ามขอบเขตเครือข่าย มันมีอินเทอร์เฟซเครือข่ายที่เหมือนกันซึ่งจะซ่อนโทโพโลยี (เค้าโครง) ที่แท้จริงของการเชื่อมต่อเครือข่ายพื้นฐาน จึงเป็นชั้นที่สร้างการเชื่อมต่ออินเทอร์เน็ตด้วย แท้จริงแล้ว มันกำหนดและสร้างอินเทอร์เน็ต เลเยอร์นี้กำหนดโครงสร้างการกำหนดที่อยู่และเส้นทางที่ใช้สำหรับชุดโปรโตคอล TCP/IP โปรโตคอลหลักในขอบเขตนี้คือ Internet Protocol ซึ่งกำหนดที่อยู่IP [41] [42]หน้าที่ของมันในการกำหนดเส้นทางคือการขนส่งดาตาแกรมไปยังโฮสต์ถัดไป ซึ่งทำหน้าที่เป็นเราเตอร์ IP ที่มีการเชื่อมต่อกับเครือข่ายใกล้กับปลายทางข้อมูลสุดท้าย[42]
  • เลเยอร์ลิงก์จะกำหนดวิธีการสร้างเครือข่ายภายในขอบเขตของลิงก์เครือข่ายท้องถิ่นที่โฮสต์สื่อสารโดยไม่มีการแทรกแซงเราเตอร์ เลเยอร์นี้ประกอบด้วยโปรโตคอลที่ใช้อธิบายโทโพโลยีเครือข่ายท้องถิ่นและอินเทอร์เฟซที่จำเป็นเพื่อให้ส่งผลต่อการส่งดาตาแกรมของเลเยอร์อินเทอร์เน็ตไปยังโฮสต์เพื่อนบ้านถัดไป[43]

เลเยอร์ลิงก์

โปรโตคอลของเลเยอร์ลิงก์ทำงานภายในขอบเขตของการเชื่อมต่อเครือข่ายท้องถิ่นที่เชื่อมต่อกับโฮสต์ ระบอบการปกครองนี้เรียกว่าลิงก์ในสำนวน TCP/IP และเป็นเลเยอร์ส่วนประกอบที่ต่ำที่สุดของชุด ลิงก์นี้รวมโฮสต์ทั้งหมดที่สามารถเข้าถึงได้โดยไม่ต้องผ่านเราเตอร์ ขนาดของลิงค์จึงถูกกำหนดโดยการออกแบบฮาร์ดแวร์เครือข่าย โดยหลักการแล้ว TCP/IP ได้รับการออกแบบมาให้ไม่ขึ้นกับฮาร์ดแวร์และอาจนำไปใช้งานบนเทคโนโลยีชั้นลิงก์ใดๆ ก็ได้ ซึ่งไม่เพียงแต่รวมถึงการใช้งานฮาร์ดแวร์เท่านั้น แต่ยัง รวม ถึงเลเยอร์ลิงก์เสมือน เช่นเครือข่ายส่วนตัวเสมือนและอุโมงค์เครือข่าย

เลเยอร์ลิงก์ใช้เพื่อย้ายแพ็กเก็ตระหว่างอินเทอร์เฟซเลเยอร์อินเทอร์เน็ตของโฮสต์ที่แตกต่างกันสองแห่งบนลิงก์เดียวกัน กระบวนการส่งและรับแพ็กเก็ตบนลิงก์สามารถควบคุมได้ในไดรเวอร์อุปกรณ์สำหรับการ์ดเครือข่ายเช่นเดียวกับในเฟิร์มแวร์หรือโดยชิปเซ็ตเฉพาะ สิ่งเหล่านี้ทำหน้าที่ต่างๆ เช่น การวางเฟรม เพื่อเตรียมแพ็กเก็ตเลเยอร์อินเทอร์เน็ตสำหรับการส่งข้อมูล และสุดท้ายจะส่งเฟรมไปยังเลเยอร์ฟิสิคัลและบนสื่อการส่งข้อมูล โมเดล TCP/IP มีข้อกำหนดสำหรับการแปลวิธีระบุที่อยู่เครือข่ายที่ใช้ใน Internet Protocol ไปเป็นที่อยู่เลเยอร์ลิงก์ เช่น ที่อยู่ Media Access Control (MAC) อย่างไรก็ตาม ด้านอื่นๆ ทั้งหมดที่ต่ำกว่าระดับนั้น จะถือว่ามีอยู่โดยปริยาย และไม่ได้กำหนดไว้อย่างชัดเจนในโมเดล TCP/IP

เลเยอร์ลิงก์ในโมเดล TCP/IP มีฟังก์ชันที่สอดคล้องกันในเลเยอร์ 2 ของโมเดล OSI

เลเยอร์อินเทอร์เน็ต

การทำงานทางอินเทอร์เน็ตจำเป็นต้องส่งข้อมูลจากเครือข่ายต้นทางไปยังเครือข่ายปลายทาง กระบวนการนี้เรียกว่าการกำหนดเส้นทางและได้รับการสนับสนุนโดยการกำหนดที่อยู่โฮสต์และการระบุตัวตนโดยใช้ระบบการกำหนดที่อยู่ IP แบบลำดับชั้น เลเยอร์อินเทอร์เน็ตมีระบบอำนวยความสะดวกในการส่งข้อมูลดาตาแกรมที่ไม่น่าเชื่อถือระหว่างโฮสต์ที่อยู่บนเครือข่าย IP ที่อาจต่างกัน โดยการส่งต่อดาตาแกรมไปยังเราเตอร์ถัดไปที่เหมาะสมเพื่อการถ่ายทอดไปยังปลายทางต่อไป เลเยอร์อินเทอร์เน็ตมีหน้าที่ส่งแพ็กเก็ตผ่านเครือข่ายที่อาจมีหลายเครือข่าย ด้วยฟังก์ชันการทำงานนี้ เลเยอร์อินเทอร์เน็ตทำให้การทำงานทางอินเทอร์เน็ตเป็นไปได้ การทำงานร่วมกันของเครือข่าย IP ที่แตกต่างกัน และสร้างอินเทอร์เน็ตขึ้นมา

เลเยอร์อินเทอร์เน็ตไม่ได้แยกความแตกต่างระหว่างโปรโตคอลเลเยอร์การขนส่งต่างๆ IP นำข้อมูลสำหรับ โปรโตคอลชั้นบนที่ แตกต่างกัน ที่หลากหลายโปรโตคอลเหล่านี้แต่ละโปรโตคอลจะถูกระบุด้วยหมายเลขโปรโตคอล ที่ไม่ซ้ำกัน เช่นInternet Control Message Protocol (ICMP) และInternet Group Management Protocol (IGMP) เป็นโปรโตคอล 1 และ 2 ตามลำดับ

Internet Protocol เป็นองค์ประกอบหลักของชั้นอินเทอร์เน็ต และกำหนดระบบที่อยู่สองระบบเพื่อระบุโฮสต์เครือข่ายและค้นหาตำแหน่งเหล่านั้นบนเครือข่าย ระบบที่อยู่ดั้งเดิมของARPANETและอินเทอร์เน็ตรุ่นต่อมาคือInternet Protocol เวอร์ชัน 4 (IPv4) ใช้ที่อยู่ IP 32 บิต และสามารถระบุโฮสต์ได้ประมาณสี่พันล้านโฮสต์ ข้อจำกัดนี้ถูกยกเลิกไปในปี 1998 โดยการกำหนดมาตรฐานของInternet Protocol เวอร์ชัน 6 (IPv6) ซึ่งใช้ที่อยู่ 128 บิต การใช้งานจริงของ IPv6 เกิดขึ้นประมาณปี พ.ศ. 2549

ชั้นขนส่ง

เลเยอร์การขนส่งจะสร้างช่องทางข้อมูลพื้นฐานที่แอปพลิเคชันใช้สำหรับการแลกเปลี่ยนข้อมูลเฉพาะงาน เลเยอร์นี้สร้างการเชื่อมต่อระหว่างโฮสต์กับโฮสต์ในรูปแบบของบริการถ่ายโอนข้อความแบบ end-to-end ที่ไม่ขึ้นอยู่กับเครือข่ายพื้นฐาน และไม่ขึ้นอยู่กับโครงสร้างของข้อมูลผู้ใช้และลอจิสติกส์ของการแลกเปลี่ยนข้อมูล การเชื่อมต่อที่ชั้นการขนส่งสามารถจัดประเภทเป็นการเชื่อมต่อเชิงนำไปใช้ใน TCP หรือไม่มีการเชื่อมต่อ ใช้งานใน UDP โปรโตคอลในเลเยอร์นี้อาจจัดให้มีการควบคุมข้อผิดพลาดการแบ่งส่วน การควบคุมการไหลการควบคุมความแออัดและการกำหนดที่อยู่แอปพลิเคชัน ( หมายเลขพอร์ต )

เพื่อวัตถุประสงค์ในการจัดหาช่องทางการส่งข้อมูลเฉพาะกระบวนการสำหรับแอปพลิเคชัน เลเยอร์จะสร้างแนวคิดของพอร์ตเครือข่าย นี่คือโครงสร้างเชิงตรรกะที่มีตัวเลขซึ่งจัดสรรไว้โดยเฉพาะสำหรับแต่ละช่องทางการสื่อสารที่แอปพลิเคชันต้องการ สำหรับบริการหลายประเภทหมายเลขพอร์ต เหล่านี้ ได้รับการกำหนดมาตรฐานเพื่อให้คอมพิวเตอร์ไคลเอนต์สามารถระบุถึงบริการเฉพาะของคอมพิวเตอร์เซิร์ฟเวอร์โดยไม่ต้องเกี่ยวข้องกับการค้นหาบริการหรือบริการไดเรกทอรี

เนื่องจาก IP จัดเตรียมการส่งมอบอย่างดีที่สุด เท่านั้น โปรโตคอลชั้นการขนส่งบางประเภทจึงมีความน่าเชื่อถือ

TCP เป็นโปรโตคอลที่เน้นการเชื่อมต่อซึ่งจัดการปัญหาความน่าเชื่อถือมากมายในการจัดเตรียมสตรีมไบต์ที่เชื่อถือได้ :

  • ข้อมูลมาตามลำดับ
  • ข้อมูลมีข้อผิดพลาดน้อยที่สุด (เช่น ความถูกต้อง)
  • ข้อมูลที่ซ้ำกันจะถูกละทิ้ง
  • แพ็กเก็ตที่สูญหายหรือถูกทิ้งจะถูกส่งอีกครั้ง
  • รวมถึงการควบคุมการจราจรติดขัด

Stream Control Transmission Protocol (SCTP) ที่ใหม่กว่ายังเป็นกลไกการขนส่งที่มุ่งเน้นการเชื่อมต่อที่เชื่อถือได้ เป็นแบบสตรีมข้อความ ไม่ใช่แบบไบต์สตรีมเหมือน TCP และจัดเตรียมสตรีมหลายรายการแบบมัลติเพล็กซ์ผ่านการเชื่อมต่อเดียว นอกจากนี้ยังให้ การสนับสนุน multihomingซึ่งจุดสิ้นสุดการเชื่อมต่อสามารถแสดงด้วยที่อยู่ IP หลายรายการ (ซึ่งแสดงถึงอินเทอร์เฟซทางกายภาพหลายรายการ) ซึ่งหากล้มเหลว การเชื่อมต่อจะไม่ถูกขัดจังหวะ ได้รับการพัฒนาในขั้นต้นสำหรับแอปพลิเคชันระบบโทรศัพท์ (เพื่อขนส่งSS7ผ่าน IP)

ความน่าเชื่อถือยังเกิดขึ้นได้ด้วยการรัน IP ผ่านโปรโตคอลดาต้าลิงค์ที่เชื่อถือได้ เช่นHigh-Level Data Link Control (HDLC)

User Datagram Protocol (UDP) เป็นโปรโตคอลดาตาแกรม แบบไร้การเชื่อมต่อ เช่นเดียวกับ IP มันเป็นโปรโตคอลที่พยายามอย่างดีที่สุดและไม่น่าเชื่อถือ ความน่าเชื่อถือได้รับการแก้ไขผ่านการตรวจหาข้อผิดพลาดโดยใช้อัลกอริธึมการตรวจสอบ โดยทั่วไป UDP ใช้สำหรับแอปพลิเคชันต่างๆ เช่น การสตรีมสื่อ (เสียง วิดีโอVoice over IPฯลฯ) ซึ่งการมาถึงที่ตรงเวลามีความสำคัญมากกว่าความน่าเชื่อถือ หรือสำหรับแอปพลิเคชันการสืบค้น/ตอบกลับอย่างง่าย เช่น การค้นหา DNSซึ่งมีค่าใช้จ่ายในการตั้งค่า การเชื่อมต่อที่เชื่อถือได้มีขนาดใหญ่ไม่สมส่วนReal-time Transport Protocol (RTP) เป็นโปรโตคอลดาตาแกรมที่ใช้บน UDP และได้รับการออกแบบมาสำหรับข้อมูลแบบเรียลไทม์ เช่นสื่อสตรีมมิ่ง

แอปพลิเคชันที่อยู่เครือข่ายที่กำหนดจะแตกต่างกันตามพอร์ต TCP หรือ UDP ตามแบบแผนพอร์ตที่รู้จัก บางพอร์ต จะเชื่อมโยงกับแอปพลิเคชันเฉพาะ

การขนส่งของโมเดล TCP/IP หรือเลเยอร์โฮสต์ถึงโฮสต์นั้นสอดคล้องกับเลเยอร์ที่สี่ในแบบจำลอง OSI หรือที่เรียกว่าเลเยอร์การขนส่ง

QUICกำลังเกิดขึ้นอย่างรวดเร็วในฐานะโปรโตคอลการขนส่งทางเลือก แม้ว่าในทางเทคนิคจะดำเนินการผ่านแพ็กเก็ต UDP แต่ก็พยายามเสนอการเชื่อมต่อการขนส่งที่ได้รับการปรับปรุงโดยสัมพันธ์กับ TCP HTTP/3ทำงานผ่าน QUIC โดยเฉพาะ

ชั้นแอปพลิเคชัน

เลเยอร์แอปพลิเคชันประกอบด้วยโปรโตคอลที่ใช้โดยแอปพลิเคชันส่วนใหญ่เพื่อให้บริการผู้ใช้หรือการแลกเปลี่ยนข้อมูลแอปพลิเคชันผ่านการเชื่อมต่อเครือข่ายที่สร้างโดยโปรโตคอลระดับล่าง ซึ่งอาจรวมถึงบริการสนับสนุนเครือข่ายพื้นฐานบางอย่าง เช่นโปรโตคอลการกำหนดเส้นทางและการกำหนดค่าโฮสต์ ตัวอย่างของโปรโตคอลเลเยอร์แอปพลิเคชัน ได้แก่Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), Simple Mail Transfer Protocol (SMTP) และDynamic Host Configuration Protocol (DHCP) [44]ข้อมูลที่เข้ารหัสตามโปรโตคอลชั้นแอปพลิเคชันจะ ถูกห่อหุ้มไว้ในหน่วยโปรโตคอลชั้นการขนส่ง (เช่นสตรีม TCP หรือดาตาแกรม UDP) ซึ่งในทางกลับกันจะใช้โปรโตคอลชั้นล่างเพื่อส่งผลต่อการถ่ายโอนข้อมูลจริง

โมเดล TCP/IP ไม่ได้คำนึงถึงลักษณะเฉพาะของการจัดรูปแบบและการนำเสนอข้อมูล และไม่ได้กำหนดเลเยอร์เพิ่มเติมระหว่างเลเยอร์แอปพลิเคชันและการขนส่ง เช่นเดียวกับในรูปแบบ OSI (เลเยอร์การนำเสนอและเซสชัน) ตามโมเดล TCP/IP ฟังก์ชันดังกล่าวคือขอบเขตของไลบรารีและอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน เลเยอร์แอปพลิเคชันในโมเดล TCP/IP มักจะถูกเปรียบเทียบกับการรวมกันของเลเยอร์ที่ห้า (เซสชัน) ที่หก (การนำเสนอ) และเลเยอร์ที่เจ็ด (แอปพลิเคชัน) ของโมเดล OSI

โปรโตคอลชั้นแอปพลิเคชันมักจะเชื่อมโยงกับ แอปพลิเคชัน ไคลเอ็นต์-เซิร์ฟเวอร์ โดยเฉพาะ และบริการทั่วไปมีหมายเลขพอร์ตที่รู้จักกันดี ซึ่งสงวนไว้โดย Internet Assigned Numbers Authority (IANA) ตัวอย่างเช่นHyperText Transfer Protocolใช้พอร์ตเซิร์ฟเวอร์ 80 และTelnetใช้พอร์ตเซิร์ฟเวอร์ 23 ไคลเอน ต์ ที่เชื่อมต่อกับบริการมักจะใช้พอร์ตชั่วคราวกล่าวคือ หมายเลขพอร์ตที่กำหนดเฉพาะในช่วงระยะเวลาของธุรกรรมโดยการสุ่มหรือจากช่วงเฉพาะที่กำหนดค่าไว้ใน แอปพลิเคชัน.

ที่เลเยอร์แอปพลิเคชัน โมเดล TCP/IP จะแยกความแตกต่างระหว่างโปรโตคอลผู้ใช้และโปรโตคอลที่รองรับ[45]โปรโตคอลสนับสนุนให้บริการแก่ระบบโครงสร้างพื้นฐานเครือข่าย โปรโตคอลผู้ใช้ใช้สำหรับแอปพลิเคชันผู้ใช้จริง ตัวอย่างเช่น FTP เป็นโปรโตคอลผู้ใช้ และ DNS เป็นโปรโตคอลสนับสนุน

แม้ว่าแอปพลิเคชันมักจะตระหนักถึงคุณสมบัติที่สำคัญของการเชื่อมต่อเลเยอร์การขนส่ง เช่น ที่อยู่ IP ปลายทางและหมายเลขพอร์ต แต่โปรโตคอลเลเยอร์แอปพลิเคชันโดยทั่วไปจะถือว่าโปรโตคอลเลเยอร์การขนส่ง (และต่ำกว่า) เป็นกล่องดำที่ให้การเชื่อมต่อเครือข่ายที่เสถียรในการสื่อสาร . เลเยอร์การขนส่งและเลเยอร์ระดับล่างไม่เกี่ยวข้องกับลักษณะเฉพาะของโปรโตคอลเลเยอร์แอปพลิเคชัน โดยทั่วไป เราเตอร์และสวิตช์จะไม่ตรวจสอบการรับส่งข้อมูลแบบห่อหุ้ม แต่จะจัดให้มีท่อสำหรับมันเท่านั้น อย่างไรก็ตาม แอปพลิเคชัน ควบคุมปริมาณไฟร์วอลล์และ แบนด์วิธบางตัว ใช้การตรวจสอบแพ็คเก็ตเชิงลึกเพื่อตีความข้อมูลแอปพลิเคชัน ตัวอย่างคือResource Reserve Protocol (RSVP) [ ต้องการอ้างอิง ]บางครั้งก็มีความจำเป็นสำหรับแอปพลิเคชันที่ได้รับผลกระทบจาก NATเพื่อพิจารณาเพย์โหลดของแอปพลิเคชัน

การแบ่งชั้นวิวัฒนาการและการเป็นตัวแทนในวรรณคดี

ชุดโปรโตคอลอินเทอร์เน็ตได้รับการพัฒนาผ่านการวิจัยและพัฒนาที่ได้รับทุนสนับสนุนในช่วงระยะเวลาหนึ่ง ในกระบวนการนี้ ข้อมูลเฉพาะของส่วนประกอบโปรโตคอลและการแบ่งชั้นขององค์ประกอบเปลี่ยนไป นอกจากนี้ การวิจัยแบบคู่ขนานและผลประโยชน์เชิงพาณิชย์จากสมาคมอุตสาหกรรมแข่งขันกันด้วยคุณสมบัติการออกแบบ โดยเฉพาะอย่างยิ่ง ความพยายามในองค์การระหว่างประเทศเพื่อการมาตรฐานนำไปสู่เป้าหมายที่คล้ายกัน แต่มีขอบเขตของเครือข่ายที่กว้างกว่าโดยทั่วไป ความพยายามในการรวมโรงเรียนหลักสองแห่งเกี่ยวกับการแบ่งชั้นซึ่งมีความคล้ายคลึงกันอย่างผิวเผิน แต่มีรายละเอียดที่แตกต่างกันอย่างมาก ทำให้ผู้เขียนตำราเรียนอิสระคิดค้นเครื่องมือการสอนที่ย่อ

ตารางต่อไปนี้แสดงโมเดลเครือข่ายต่างๆ ดังกล่าว จำนวนชั้นจะแตกต่างกันไประหว่างสามถึงเจ็ดชั้น

โมเดลอ้างอิง Arpanet
(RFC 871)
มาตรฐานอินเทอร์เน็ต
(RFC 1122)
รุ่นอินเทอร์เน็ต
(Cisco Academy [46] )
โมเดลอ้างอิง TCP/IP 5 ชั้น
(Kozierok, [47] Comer [48] )
โมเดลอ้างอิง TCP/IP 5 ชั้น
(Tanenbaum [49] )
ชุดโปรโตคอล TCP/IP หรือโมเดลอินเทอร์เน็ตห้าชั้น
(Forouzan, [50] Kurose [51] )
โมเดล TCP/IP
(การหยุดนิ่ง[52] )
แบบจำลอง OSI
(ISO/IEC 7498-1:1994 [53] )
สามชั้น สี่ชั้น สี่ชั้น สี่+หนึ่งชั้น ห้าชั้น ห้าชั้น ห้าชั้น เจ็ดชั้น
ขั้นตอนการสมัคร แอปพลิเคชัน แอปพลิเคชัน แอปพลิเคชัน แอปพลิเคชัน แอปพลิเคชัน แอปพลิเคชัน แอปพลิเคชัน
การนำเสนอ
การประชุม
โฮสต์ถึงโฮสต์ ขนส่ง ขนส่ง ขนส่ง ขนส่ง ขนส่ง โฮสต์ถึงโฮสต์หรือการขนส่ง ขนส่ง
อินเทอร์เน็ต งานอินเตอร์เน็ต อินเทอร์เน็ต อินเทอร์เน็ต เครือข่าย อินเทอร์เน็ต เครือข่าย
เชื่อมต่อเครือข่าย ลิงค์ เชื่อมต่อเครือข่าย ลิงค์ข้อมูล (อินเทอร์เฟซเครือข่าย) ลิงค์ข้อมูล ลิงค์ข้อมูล การเข้าถึงเครือข่าย ลิงค์ข้อมูล
- - - (ฮาร์ดแวร์) ทางกายภาพ ทางกายภาพ ทางกายภาพ ทางกายภาพ

โมเดลเครือข่ายบางโมเดลมาจากตำราเรียน ซึ่งเป็นแหล่งข้อมูลรองที่อาจขัดแย้งกับเจตนาของ RFC 1122 และแหล่งข้อมูลหลักIETF อื่นๆ [54]

การเปรียบเทียบการแบ่งชั้น TCP/IP และ OSI

เลเยอร์บนสุดสามเลเยอร์ในโมเดล OSI กล่าวคือ เลเยอร์แอปพลิเคชัน เลเยอร์การนำเสนอ และเลเยอร์เซสชัน จะไม่แยกความแตกต่างแยกจากกันในโมเดล TCP/IP ซึ่งมีเพียงเลเยอร์แอปพลิเคชันเหนือเลเยอร์การขนส่ง แม้ว่าแอปพลิเคชันโปรโตคอล OSI บางตัว เช่นX.400จะรวมแอปพลิเคชันเหล่านั้นเข้าด้วยกัน แต่ไม่มีข้อกำหนดที่สแต็กโปรโตคอล TCP/IP จะต้องกำหนดสถาปัตยกรรมแบบเสาหินเหนือเลเยอร์การขนส่ง ตัวอย่างเช่น โปรโตคอลแอปพลิเคชัน NFS รันบน โปรโตคอลการนำเสนอ External Data Representation (XDR) ซึ่งในทางกลับกัน รันบนโปรโตคอลที่เรียกว่าRemote Procedure Call (RPC) RPC ให้การส่งบันทึกที่เชื่อถือได้ ดังนั้นจึงสามารถใช้การขนส่ง UDP ได้อย่างเต็มประสิทธิภาพได้อย่างปลอดภัย

ผู้เขียนที่แตกต่างกันตีความโมเดล TCP/IP แตกต่างกัน และไม่เห็นด้วยว่าเลเยอร์ลิงก์หรือลักษณะใดๆ ของโมเดล TCP/IP ครอบคลุมปัญหาเลเยอร์ OSI 1 ( เลเยอร์ทางกายภาพ ) หรือไม่ หรือ TCP/IP ถือว่าเลเยอร์ฮาร์ดแวร์มีอยู่ด้านล่าง เลเยอร์ลิงก์

ผู้เขียนหลายคนพยายามที่จะรวมเลเยอร์ 1 และ 2 ของโมเดล OSI เข้ากับโมเดล TCP/IP เนื่องจากสิ่งเหล่านี้มักถูกอ้างถึงในมาตรฐานสมัยใหม่ (เช่น โดยIEEEและITU ) ซึ่งมักจะส่งผลให้โมเดลมีห้าเลเยอร์ โดยที่เลเยอร์ลิงก์หรือเลเยอร์การเข้าถึงเครือข่ายจะถูกแบ่งออกเป็นเลเยอร์ 1 และ 2 ของโมเดล OSI

ความพยายามในการพัฒนาโปรโตคอล IETF ไม่ได้เกี่ยวข้องกับการแบ่งชั้นที่เข้มงวด โปรโตคอลบางตัวอาจไม่พอดีกับโมเดล OSI อย่างสมบูรณ์ แม้ว่าบางครั้ง RFC จะอ้างถึงและมักใช้หมายเลขเลเยอร์ OSI เก่าก็ตาม IETF ได้ระบุซ้ำแล้วซ้ำอีก[55]ว่าอินเทอร์เน็ตโปรโตคอลและการพัฒนาสถาปัตยกรรมไม่ได้มีวัตถุประสงค์เพื่อให้สอดคล้องกับ OSI RFC 3439 ซึ่งอ้างถึงสถาปัตยกรรมอินเทอร์เน็ต มีส่วนที่มีชื่อว่า: "การเลเยอร์ถือว่าเป็นอันตราย"

ตัวอย่างเช่น เซสชันและเลเยอร์การนำเสนอของชุด OSI จะถือว่ารวมอยู่ในเลเยอร์แอปพลิเคชันของชุด TCP/IP การทำงานของเลเยอร์เซสชันสามารถพบได้ในโปรโตคอล เช่นHTTPและSMTPและเห็นได้ชัดเจนมากขึ้นในโปรโตคอล เช่นTelnetและSession Initiation Protocol (SIP) ฟังก์ชันการทำงานของเซสชันเลเยอร์ยังเกิดขึ้นได้ด้วยการกำหนดหมายเลขพอร์ตของโปรโตคอล TCP และ UDP ซึ่งรวมอยู่ในเลเยอร์การขนส่งของชุด TCP/IP ฟังก์ชันของเลเยอร์การนำเสนอเกิดขึ้นได้ในแอปพลิเคชัน TCP/IP ที่มี มาตรฐาน MIMEในการแลกเปลี่ยนข้อมูล

ข้อแตกต่างก็คือในการรักษาโปรโตคอลการกำหนดเส้นทาง โปรโตคอลการกำหนดเส้นทาง OSI IS-ISเป็นของเลเยอร์เครือข่าย และไม่ได้ขึ้นอยู่กับCLNSในการส่งแพ็กเก็ตจากเราเตอร์ตัวหนึ่งไปยังอีกตัวหนึ่ง แต่กำหนดการห่อหุ้มเลเยอร์ 3 ของตัวเอง ในทางตรงกันข้ามOSPF , RIP , BGPและโปรโตคอลการกำหนดเส้นทางอื่นๆ ที่กำหนดโดย IETF จะถูกส่งผ่าน IP และเพื่อวัตถุประสงค์ในการส่งและรับแพ็กเก็ตโปรโตคอลการกำหนดเส้นทาง เราเตอร์จะทำหน้าที่เป็นโฮสต์ ด้วยเหตุนี้RFC  1812 จึงรวมโปรโตคอลการกำหนดเส้นทางไว้ในเลเยอร์แอปพลิเคชัน ผู้เขียนบางคน เช่น Tanenbaum ในComputer Networksอธิบายโปรโตคอลการกำหนดเส้นทางในเลเยอร์เดียวกันกับ IP โดยให้เหตุผลว่าโปรโตคอลการกำหนดเส้นทางแจ้งการตัดสินใจที่ทำโดยกระบวนการส่งต่อของเราเตอร์

โปรโตคอล IETF สามารถห่อหุ้มแบบเรียกซ้ำได้ ดังที่แสดงโดยโปรโตคอลทันเนล เช่นGeneric Routing Encapsulation (GRE) GRE ใช้กลไกเดียวกับที่ OSI ใช้สำหรับการขุดอุโมงค์ที่เลเยอร์เครือข่าย

การดำเนินการ

ชุดอินเทอร์เน็ตโปรโตคอลไม่ได้คำนึงถึงสภาพแวดล้อมของฮาร์ดแวร์หรือซอฟต์แวร์เฉพาะใดๆ ต้องการเพียงฮาร์ดแวร์และซอฟต์แวร์ที่มีความสามารถในการส่งและรับแพ็กเก็ตบนเครือข่ายคอมพิวเตอร์เท่านั้น ด้วยเหตุนี้ ชุดโปรแกรมดังกล่าวจึงถูกนำไปใช้กับแพลตฟอร์มคอมพิวเตอร์ทุกเครื่องเป็นหลัก การใช้งาน TCP/IP ขั้นต่ำมีดังต่อไปนี้: Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP) และInternet Group Management โปรโตคอล (IGMP) นอกจาก IP, ICMP, TCP, UDP แล้ว Internet Protocol เวอร์ชัน 6 ยังต้องใช้Neighbor Discovery Protocol (NDP), ICMPv6และMulticast Listener Discovery (MLD) และมักจะมาพร้อมกับเลเยอร์ความปลอดภัย IPSec ในตัว

ดูสิ่งนี้ด้วย

หมายเหตุ

  1. ดู Abbate, Inventing the Internet , 129–30; วินตัน จี. เซิร์ฟ (ตุลาคม 1980) "โปรโตคอลสำหรับเครือข่ายแพ็คเก็ตที่เชื่อมต่อถึงกัน" ทบทวนการสื่อสารคอมพิวเตอร์ ACM SIGCOMM 10 (4): 10–11.- และRFC 760 ดอย : 10.17487/ RFC0760- สำหรับบันทึกการสนทนาที่นำไปสู่การแยก TCP/IP โปรดดูชุดบันทึกการทดลองอินเทอร์เน็ตที่ดัชนีบันทึกการทดลองอินเทอร์เน็ต

อ้างอิง

  1. ↑ อับ เบรเดน อาร์.เอ็ด. (ตุลาคม 2532). ข้อกำหนดสำหรับโฮสต์อินเทอร์เน็ต – เลเยอร์การสื่อสารดอย : 10.17487/RFC1122 . อาร์เอฟซี 1122
  2. แบรเดน อาร์.เอ็ด. (ตุลาคม 2532). ข้อกำหนดสำหรับโฮสต์อินเทอร์เน็ต – แอปพลิเคชันและการสนับสนุนดอย : 10.17487/RFC1123 . อาร์เอฟซี 1123
  3. เซอร์ฟ, วินตัน จี. และเคน, เอ็ดเวิร์ด (ตุลาคม 1983) "โมเดลสถาปัตยกรรมอินเทอร์เน็ตของกระทรวงกลาโหม" เครือข่ายคอมพิวเตอร์ . 7 (5) ฮอลแลนด์เหนือ: 307–318 ดอย :10.1016/0376-5075(83)90042-9.
  4. เรย์โนลด์ส เจ.; โพสเทล, เจ. (1987). คู่มืออ้างอิงการขอความคิดเห็นดอย : 10.17487/RFC1000 . อาร์เอฟซี 1000.
  5. ฮาฟเนอร์, เคธี่; ลียง, แมทธิว (1996) ที่ที่พ่อมดนอนดึก : ต้นกำเนิดของอินเทอร์เน็ต คลังอินเทอร์เน็ต นิวยอร์ก : ไซมอน แอนด์ ชูสเตอร์. พี 263. ไอเอสบีเอ็น 978-0-684-81201-4-
  6. รัสเซลล์, แอนดรูว์ แอล. (2014) มาตรฐานเปิดและยุคดิจิทัล: ประวัติศาสตร์ อุดมการณ์ และเครือข่าย นิวยอร์ก: สำนักพิมพ์มหาวิทยาลัยเคมบริดจ์. พี 196. ไอเอสบีเอ็น 978-1107039193- เก็บถาวรจากต้นฉบับเมื่อวันที่ 28 ธันวาคม 2022 . สืบค้นเมื่อ 20 ธันวาคม 2022 .
  7. อับบาเต, เจเน็ต (2000) การประดิษฐ์อินเทอร์เน็ต สำนักพิมพ์เอ็มไอที. หน้า 123–123–4. ไอเอสบีเอ็น 978-0-262-51115-5- เก็บถาวรจากต้นฉบับเมื่อวันที่ 17 มกราคม 2023 . สืบค้นเมื่อวันที่ 15 พฤษภาคม 2020 .
  8. Taylor, Bob (11 ตุลาคม 2551), "Oral History of Robert (Bob) W. Taylor" (PDF) , เอกสารพิพิธภัณฑ์ประวัติศาสตร์คอมพิวเตอร์ , CHM หมายเลขอ้างอิง: X5059.2009: 28
  9. ไอแซ็กสัน, วอลเตอร์ (2014) นักนวัตกรรม: กลุ่มแฮกเกอร์ อัจฉริยะ และคนเกินบรรยายสร้างการปฏิวัติทางดิจิทัลได้อย่างไร คลังอินเทอร์เน็ต นิวยอร์ก : ไซมอน แอนด์ ชูสเตอร์. ไอเอสบีเอ็น 978-1-4767-0869-0-
  10. เซอร์ฟ, วี.; คาห์น อาร์. (1974) "โปรโตคอลสำหรับการสื่อสารภายในเครือข่ายแพ็กเก็ต" (PDF ) ธุรกรรม IEEE เกี่ยวกับการสื่อสาร22 (5): 637–648. ดอย :10.1109/TCOM.1974.1092259. ISSN  1558-0857. เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 10 ตุลาคม 2022 . สืบค้นเมื่อวันที่ 18 ตุลาคม 2558 . ผู้เขียนขอขอบคุณเพื่อนร่วมงานจำนวนหนึ่งสำหรับความคิดเห็นที่เป็นประโยชน์ในระหว่างการอภิปรายเกี่ยวกับโปรโตคอลเครือข่ายระหว่างประเทศในช่วงแรกๆ โดยเฉพาะ R. Metcalfe, R. Scantlebury, D. Walden และ H. Zimmerman D. Davies และ L. Pouzin ผู้ที่แสดงความคิดเห็นอย่างสร้างสรรค์เกี่ยวกับประเด็นการกระจายตัวและการบัญชี และ S. Crocker ที่ให้ความเห็นเกี่ยวกับการสร้างและการทำลายสมาคม
  11. "ชายคนที่ห้าแห่งอินเทอร์เน็ต". นักเศรษฐศาสตร์ . 13 ธันวาคม 2013. เก็บถาวรจากต้นฉบับเมื่อวันที่ 19 เมษายน 2020 . สืบค้นเมื่อวันที่ 11 กันยายน 2017 . ในช่วงต้นทศวรรษ 1970 คุณ Pouzin ได้สร้างเครือข่ายข้อมูลเชิงนวัตกรรมที่เชื่อมโยงสถานที่ต่างๆ ในฝรั่งเศส อิตาลี และอังกฤษ ความเรียบง่ายและประสิทธิภาพของมันชี้ให้เห็นถึงเครือข่ายที่สามารถเชื่อมต่อได้ไม่เพียงแค่เครื่องหลายสิบเครื่องเท่านั้น แต่ยังเชื่อมต่อได้หลายล้านเครื่องอีกด้วย มันสะท้อนจินตนาการของ Dr Cerf และ Dr Kahn ซึ่งรวมแง่มุมต่างๆ ของการออกแบบไว้ในโปรโตคอลที่ขับเคลื่อนอินเทอร์เน็ตในปัจจุบัน
  12. เซิร์ฟ, วินตัน ; ดาลาล, โยเกน ; ซันไชน์, คาร์ล (ธันวาคม 2517) ข้อมูลจำเพาะของโปรโตคอลควบคุมการส่งสัญญาณอินเทอร์เน็ตดอย : 10.17487/RFC0675 . อาร์เอฟซี 675.
  13. เซิร์ฟ, วินตัน (มีนาคม 1977) "ข้อมูลจำเพาะของโปรโตคอลควบคุมการส่งข้อมูลอินเทอร์เน็ต TCP (เวอร์ชัน 2)" (PDF ) เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 25 พฤษภาคม 2022 . สืบค้นเมื่อ 4 สิงหาคม 2022 .
  14. หอเกียรติยศอินเทอร์เน็ต
  15. ปันซาริส, จอร์จิออส (2008) เครื่องจักรและความโรแมนติค: การสร้างทางเทคนิคและการเล่าเรื่องของการประมวลผลแบบเครือข่ายเป็นแพลตฟอร์มอเนกประสงค์ พ.ศ. 2503-2538 มหาวิทยาลัยสแตนฟอร์ด . พี 128. เก็บถาวรจากต้นฉบับเมื่อวันที่ 17 มกราคม 2023 . สืบค้นเมื่อวันที่ 5 กันยายน 2019 .
  16. เพลคีย์, เจมส์ แอล. (2007) "โยเกน ดาลาล" ทุนนิยมผู้ประกอบการและนวัตกรรม: ประวัติศาสตร์การสื่อสารคอมพิวเตอร์ พ.ศ. 2511-2531 เก็บถาวรจากต้นฉบับเมื่อวันที่ 8 ตุลาคม 2022 . สืบค้นเมื่อวันที่ 8 ตุลาคม 2020 .
  17. Postel, Jon (15 สิงหาคม 1977), 2.3.3.2 ความคิดเห็นเกี่ยวกับ Internet Protocol และ TCP, IEN 2, เก็บถาวรจากต้นฉบับเมื่อวันที่ 16 พฤษภาคม 2019 ดึงข้อมูลเมื่อ11 มิถุนายน 2016
  18. รัสเซลล์, แอนดรูว์ แอล. (2007) "สภานิติบัญญัติอุตสาหกรรม": การกำหนดมาตรฐานฉันทามติในการปฏิวัติอุตสาหกรรมครั้งที่สองและสาม(PDF) (วิทยานิพนธ์ระดับปริญญาเอก) มหาวิทยาลัยจอห์น ฮอปกินส์. เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 28 ธันวาคม2022 สืบค้นเมื่อวันที่ 28 ธันวาคม 2022 .
  19. โดย Vinton Cerf, ตามที่บอกกับ Bernard Aboba (1993) "อินเทอร์เน็ตเกิดขึ้นได้อย่างไร" เก็บถาวรจากต้นฉบับเมื่อวันที่ 26 กันยายน 2017 . สืบค้นเมื่อวันที่ 25 กันยายน 2017 . เราเริ่มใช้งานพร้อมกันที่ Stanford, BBN และ University College London ดังนั้นความพยายามในการพัฒนาโปรโตคอลอินเทอร์เน็ตจึงเป็นระดับสากลตั้งแต่เริ่มต้น
  20. เบเกอร์ เอฟ. (มิถุนายน 1995) ข้อกำหนดสำหรับเราเตอร์ IP เวอร์ชัน 4 ดอย : 10.17487/RFC1812 . อาร์เอฟซี 1812
  21. โครเวลล์, วิลเลียม; คอนตอส, ไบรอัน; เดโรเดฟฟ์, โคลบี (2011) การหลอมรวมความปลอดภัยทางกายภาพและลอจิคัล: ขับเคลื่อนโดยการจัดการความปลอดภัยระดับองค์กร ซินเกรส พี 99. ไอเอสบีเอ็น 9780080558783-
  22. ↑ อับ รอนดา เฮาเบน. "จาก ARPANET สู่อินเทอร์เน็ต" TCP Digest (UUCP) เก็บถาวรจากต้นฉบับเมื่อวันที่ 21 กรกฎาคม 2009 . สืบค้นเมื่อ 5 กรกฎาคม 2550 .
  23. "บันทึกสำหรับเลขานุการของประธานกรมทหารของหัวหน้าคณะเสนาธิการร่วมของหน่วยงานกลาโหม" มีนาคม 1982.
  24. เฮาเบน, รอนดา (2004) "อินเทอร์เน็ต: ต้นกำเนิดระหว่างประเทศและวิสัยทัศน์ความร่วมมือ" นักคอมพิวเตอร์สมัครเล่น . 12 (2) . สืบค้นเมื่อวันที่ 29 พฤษภาคม 2552 . มี.ค. 82 – นอร์เวย์ออกจาก ARPANET และกลายเป็นการเชื่อมต่ออินเทอร์เน็ตผ่าน TCP/IP ผ่าน SATNET พ.ย. 82 – UCL ออกจาก ARPANET และกลายเป็นการเชื่อมต่ออินเทอร์เน็ต
  25. "อินเทอร์เน็ตโปรโตคอล TCP/IP". เก็บถาวรจากต้นฉบับเมื่อวันที่ 1 มกราคม 2018 . สืบค้นเมื่อวันที่ 31 ธันวาคม 2017 .
  26. ไลเนอร์, แบร์รี เอ็ม.; และคณะ (1997), ประวัติโดยย่อของอินเทอร์เน็ต(PDF) , สังคมอินเทอร์เน็ต , หน้า. 15, เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 18 มกราคม 2018 , ดึงข้อมูลเมื่อวันที่ 17 มกราคม 2018
  27. "การใช้ Wollongong TCP/IP กับ Windows สำหรับ Workgroups 3.11" ฝ่ายสนับสนุน ของไมโครซอฟต์เก็บถาวรจากต้นฉบับเมื่อวันที่ 12 มกราคม 2012
  28. "ประวัติโดยย่อของอินเทอร์เน็ตโปรโตคอลที่ CERN". เก็บถาวรจากต้นฉบับเมื่อวันที่ 10 พฤศจิกายน 2016 . สืบค้นเมื่อ 12 กันยายน 2559 .
  29. เบเกอร์, สตีเว่น; กิลลีส์, โดนัลด์ ดับเบิลยู. "เดสก์ท็อป TCP/IP ในวัยกลางคน" เก็บถาวรจากต้นฉบับเมื่อวันที่ 21 สิงหาคม 2015 . สืบค้นเมื่อวันที่ 9 กันยายน 2559 .
  30. รอมคีย์, จอห์น (17 กุมภาพันธ์ พ.ศ. 2554). "เกี่ยวกับ". เก็บถาวรจากต้นฉบับเมื่อ 5 พฤศจิกายน 2011 . สืบค้นเมื่อ 12 กันยายน 2559 .
  31. Phil Karn, เว็บไซต์ดาวน์โหลด TCP ของ KA9Q
  32. แอนดรูว์ แอล. รัสเซลล์ (30 กรกฎาคม พ.ศ. 2556) "OSI: อินเทอร์เน็ตที่ไม่ใช่" สเปกตรัมIEEEฉบับที่ 50 ไม่ 8. เก็บถาวรจากต้นฉบับเมื่อวันที่ 1 สิงหาคม 2017 . สืบค้นเมื่อวันที่ 6 กุมภาพันธ์ 2020 .
  33. รัสเซลล์, แอนดรูว์ แอล. "ฉันทามติคร่าวๆ และโค้ดรันนิ่ง" และสงครามมาตรฐาน OSI ของอินเทอร์เน็ต(PDF ) พงศาวดาร IEEE แห่งประวัติศาสตร์คอมพิวเตอร์ เก็บถาวรจากต้นฉบับ(PDF)เมื่อวันที่ 17 พฤศจิกายน 2019
  34. ↑ อับ เดวีส์, ฮาวเวิร์ด; เบรสสัน, เบียทริซ (26 เมษายน 2553) ประวัติความเป็นมาของเครือข่ายการวิจัยระหว่างประเทศ: คนที่ทำให้มันเกิดขึ้น จอห์น ไวลีย์ แอนด์ ซันส์ไอเอสบีเอ็น 978-3-527-32710-2- เก็บถาวรจากต้นฉบับเมื่อวันที่ 17 มกราคม 2023 . สืบค้นเมื่อวันที่ 7 พฤศจิกายน 2020 .
  35. โมราบิโต, โรแบร์โต; ฆิเมเนซ, ไจเม่ (มิถุนายน 2020). "IETF Protocol Suite สำหรับ Internet of Things: ภาพรวมและความก้าวหน้าล่าสุด" นิตยสารมาตรฐานการสื่อสาร IEEE 4 (2): 41–49. arXiv : 2003.10279 . ดอย :10.1109/mcomstd.001.1900014. ISSN  2471-2825.
  36. บลูเมนธาล, มาร์จอรี เอส.; คลาร์ก, เดวิด ดี. (สิงหาคม 2544) "คิดใหม่เกี่ยวกับการออกแบบอินเทอร์เน็ต: ข้อโต้แย้งจากต้นทางถึงปลายทางกับโลกใหม่ที่กล้าหาญ" (PDF ) เก็บถาวร(PDF)จากต้นฉบับเมื่อวันที่ 8 ตุลาคม 2022 . สืบค้นเมื่อ 8 ตุลาคม 2022 .
  37. จอน โพสเทล, เอ็ด. (กันยายน 2524). ข้อกำหนดโปรโตคอลอินเทอร์เน็ตของโปรแกรมอินเทอร์เน็ต DARPA พี 23. ดอย : 10.17487/RFC0791 . อาร์เอฟซี 791
  38. อาร์. แบรเดน , เอ็ด. (ตุลาคม 2532). ข้อกำหนดสำหรับโฮสต์อินเทอร์เน็ต – เลเยอร์การสื่อสาร พี 13. ดอย : 10.17487/RFC1122 . อาร์เอฟซี 1122
  39. บี. ช่างไม้, เอ็ด. (มิถุนายน 2539). หลักการทางสถาปัตยกรรมของอินเทอร์เน็ตดอย : 10.17487/RFC1958 . อาร์เอฟซี 1958.
  40. ฮันต์, เครก (2002) การบริหารเครือข่าย TCP/IP (ฉบับที่ 3) โอ'ไรลี่. หน้า 9–10. ไอเอสบีเอ็น 9781449390785-
  41. กัตต์แมน, อี. (1999) "โปรโตคอลตำแหน่งบริการ: การค้นหาบริการเครือข่าย IP โดยอัตโนมัติ" คอมพิวเตอร์อินเทอร์เน็ต IEEE 3 (4): 71–80. ดอย :10.1109/4236.780963. ISSN  1089-7801.
  42. ↑ ab Zheng, Kai (กรกฎาคม 2017) "การเปิดใช้งาน "การกำหนดเส้นทางโปรโตคอล": ทบทวนการออกแบบโปรโตคอลเลเยอร์การขนส่งในการสื่อสารทางอินเทอร์เน็ต" คอมพิวเตอร์อินเทอร์เน็ต IEEE 21 (6): 52–57. ดอย :10.1109/mic.2017.4180845. ISSN  1089-7801.
  43. หวง, จิงเหลียน (7 เมษายน พ.ศ. 2552) "โครงการปรับการเชื่อมโยงข้ามเลเยอร์ในเครือข่ายท้องถิ่นไร้สาย" วารสารการประยุกต์ใช้คอมพิวเตอร์ . 29 (2): 518–520. ดอย :10.3724/sp.j.1087.2009.00518. ISSN  1001-9081.
  44. สตีเวนส์, ดับเบิลยู. ริชาร์ด (กุมภาพันธ์ พ.ศ. 2537) TCP/IP ภาพประกอบ: โปรโตคอลไอเอสบีเอ็น 0-201-63346-9- เก็บถาวรจากต้นฉบับเมื่อวันที่ 22 เมษายน 2012 . สืบค้นเมื่อ 25 เมษายน 2555 .
  45. "1.1.3 ชุดอินเทอร์เน็ตโปรโตคอล". ข้อกำหนดสำหรับโฮสต์อินเทอร์เน็ต – เลเยอร์การสื่อสาร 1989. หน้า. 9. ดอย : 10.17487/RFC1122 . อาร์เอฟซี 1122
  46. ย้อม, มาร์ค; แมคโดนัลด์, ริก; รูฟี, อันทูน (29 ตุลาคม 2550). ความรู้พื้นฐานด้านเครือข่าย, คู่มือสหายการสำรวจ CCNA สำนักพิมพ์ซิสโก้. ไอเอสบีเอ็น 9780132877435- สืบค้นเมื่อวันที่ 12 กันยายน 2559 - ผ่าน Google หนังสือ
  47. Kozierok, Charles M. (1 มกราคม พ.ศ. 2548) คู่มือ TCP/IP: ข้อมูลอ้างอิงโปรโตคอลอินเทอร์เน็ตที่มีภาพประกอบอย่างครอบคลุม ไม่มีการกดแป้งไอเอสบีเอ็น 9781593270476- สืบค้นเมื่อวันที่ 12 กันยายน 2559 - ผ่าน Google หนังสือ
  48. โคเมอร์, ดักลาส (1 มกราคม พ.ศ. 2549) การทำงานบนอินเทอร์เน็ตด้วย TCP/IP: หลักการ โปรโตคอล และสถาปัตยกรรม ศิษย์ฮอลล์. ไอเอสบีเอ็น 0-13-187671-6- สืบค้นเมื่อวันที่ 12 กันยายน 2559 - ผ่าน Google หนังสือ
  49. ทาเน็นบัม, แอนดรูว์ เอส. (1 มกราคม พ.ศ. 2546) เครือข่ายคอมพิวเตอร์ . ห้องฝึกหัด PTR. พี 42. ไอเอสบีเอ็น 0-13-066102-3- สืบค้นเมื่อวันที่ 12 กันยายน 2559 - จาก Internet Archive เครือข่าย
  50. โฟรูซาน, เบห์รูซ เอ.; เฟแกน, โซเฟีย ชุง (1 สิงหาคม 2546) การสื่อสารข้อมูลและเครือข่าย การศึกษาระดับอุดมศึกษา McGraw-Hill ไอเอสบีเอ็น 9780072923544- สืบค้นเมื่อวันที่ 12 กันยายน 2559 - ผ่าน Google หนังสือ
  51. คุโรเสะ, เจมส์ เอฟ.; รอสส์, คีธ ดับเบิลยู. (2008) ระบบเครือข่ายคอมพิวเตอร์: วิธีการจากบนลงล่าง เพียร์สัน/แอดดิสัน เวสลีย์. ไอเอสบีเอ็น 978-0-321-49770-3- เก็บถาวรจากต้นฉบับเมื่อวันที่ 23 มกราคม 2016 . สืบค้นเมื่อ 16 กรกฎาคม 2551 .
  52. สตอลลิงส์, วิลเลียม (1 มกราคม พ.ศ. 2550) ข้อมูลและการสื่อสารคอมพิวเตอร์ ศิษย์ฮอลล์. ไอเอสบีเอ็น 978-0-13-243310-5- สืบค้นเมื่อวันที่ 12 กันยายน 2559 - ผ่าน Google หนังสือ
  53. ISO/IEC 7498-1:1994 เทคโนโลยีสารสนเทศ — การเชื่อมต่อระหว่างระบบเปิด — โมเดลอ้างอิงพื้นฐาน: โมเดลพื้นฐาน
  54. บุช, อาร์.; เมเยอร์, ​​D., eds. (ธันวาคม 2545). หลักเกณฑ์และปรัชญาทางสถาปัตยกรรมอินเทอร์เน็ตบางประการดอย : 10.17487/RFC3439 . อาร์เอฟซี 3439
  55. "ความรู้เบื้องต้นเกี่ยวกับ IETF". ไอทีเอฟ. สืบค้นเมื่อ 27 กุมภาพันธ์ 2024 .

บรรณานุกรม

ลิงค์ภายนอก

  • ประวัติอินเทอร์เน็ต – หน้าของ Robert Kahn, Vinton Cerf และ TCP/IP (ตรวจสอบโดย Cerf และ Kahn)
  • RFC 1180 บทช่วยสอน TCP/IP – จาก Internet Engineering Task Force (มกราคม 1991)
  • คู่มือขั้นสูงสำหรับ TCP/IP
  • คู่มือ TCP/IP – ข้อมูลที่ครอบคลุมเกี่ยวกับโปรโตคอล ตลอดจนขั้นตอนและกระบวนการที่เกี่ยวข้อง
  • การศึกษา ARPANET TCP/IP Digest ซึ่งเก็บถาวรจากต้นฉบับเมื่อวันที่ 4 ธันวาคม 2021
Retrieved from "https://en.wikipedia.org/w/index.php?title=Internet_protocol_suite&oldid=1216244527"