แม้ว่าข้อความในคอมพิวเตอร์จะแตกต่างกันในการใช้คำนี้ แต่ Ubuntu ใช้ TCP Maximum Transmission Unit (MTU) เพื่ออ้างถึงขนาดที่ใหญ่ที่สุดของแพ็กเก็ต TCP ที่เครื่องสามารถส่งผ่านการเชื่อมต่อเครือข่าย TCP / IP แม้ว่าการคำนวณค่านี้จะค่อนข้างง่ายและค่าเริ่มต้นจะใช้ได้กับเครื่องส่วนใหญ่ แต่อาจเป็นไปได้ที่จะเพิ่มประสิทธิภาพระบบของคุณเพิ่มเติมหากแพ็กเก็ตแตกเป็นส่วน ๆ เนื่องจากการตั้งค่าที่ผิดปกติ การส่งแพ็กเก็ตขาออกเดี่ยวขนาดใหญ่จะมีประสิทธิภาพมากกว่าการส่งแพ็กเก็ตขาออกขนาดเล็กหลาย ๆ
วิธีที่ง่ายที่สุดในการค้นหาค่า MTU ที่ถูกต้องสำหรับเครื่องของคุณคือการเปิดหน้าต่างเทอร์มินัล กด CTRL, ATL และ T ค้างไว้หรืออาจเริ่มจากเส้นประ Unity หากคุณทำงานกับ Ubuntu Server คุณจะใช้อินเทอร์เฟซ CLI เป็นค่าเริ่มต้นโดยไม่มีสภาพแวดล้อมแบบกราฟิกเลย เมื่อคุณอยู่ที่เครื่องเทอร์มินัลให้พิมพ์ ping -s 1464 -c1 distrowatch.com แล้วรอผลลัพธ์ หากคุณไม่ได้รับสิ่งใดแสดงว่าการเชื่อมต่อเครือข่ายของคุณไม่ได้รับการกำหนดค่าอย่างถูกต้อง สมมติว่าคุณได้รับเอาต์พุตที่เหมาะสมจากนั้นมองหาส่วนที่อ่านข้อมูล 1464 (1492) ไบต์ซึ่งระบุว่าคุณกำลังส่งแพ็กเก็ตโดยมีข้อมูลส่วนหัว 28 ไบต์
วิธีที่ 1: การตรวจสอบผลลัพธ์ ping สำหรับ Packet Fragmentation
คำสั่ง ping จะแจ้งให้คุณทราบว่าแพ็กเก็ตถูกส่งเป็นมากกว่าหนึ่งแฟรกเมนต์พร้อมแนบข้อมูลส่วนหัวหลายรายการ ตรวจสอบผลลัพธ์สำหรับบรรทัดใด ๆ ที่เตือนเกี่ยวกับบางสิ่งเกี่ยวกับ“ Frag needed และ DF set (mtu = 1492)” หรือข้อความที่คล้ายกัน ขึ้นอยู่กับเวอร์ชันของ ping ที่รวมอยู่ใน Ubuntu เวอร์ชันของคุณคำเตือนอาจใช้คำต่างกัน หากไม่มีข้อความนี้แสดงว่าคุณกำลังดำเนินการกับการวัด MTU บางอย่างอยู่แล้วซึ่งไม่ได้ส่งแพ็กเก็ตที่กระจัดกระจายออกไปในปัจจุบัน
ในการค้นหา MTU ที่ปรับให้เหมาะสมที่สุดสำหรับระบบของคุณคุณต้องเรียกใช้คำสั่ง ping นี้ด้วยขนาดแพ็คเก็ตขนาดเล็กจากนั้นเมื่อเวลาผ่านไปจะเพิ่มขึ้นจนกว่าจะเริ่มแยกส่วนหลังจากนั้นคุณจะพิจารณาจุดตัดของคุณ โปรดทราบว่า MTU = payload + 28 เนื่องจากต้องมีที่ว่างสำหรับข้อมูลส่วนหัว ตอนนี้หากคุณสามารถเพิ่มขนาดให้ใหญ่มากโดยไม่ต้องมีชิ้นส่วนใด ๆ อินเทอร์เฟซเครือข่ายของคุณอาจรองรับแพ็กเก็ตขนาดใหญ่ได้โดยไม่จำเป็นต้องสร้างชิ้นส่วน ในที่สุดเมื่อคุณเห็นคำเตือนที่จำเป็นของ Frag นั่นหมายความว่าแพ็กเก็ตใด ๆ ที่ส่งมาพร้อมกับน้ำหนักบรรทุกขนาดที่คุณรันหรือสูงกว่าจะส่งเป็นหลายแพ็กเก็ต สมมติว่าถ้าคุณลอง ping -s 2464 -c1 distrowatch.com โดยไม่มีคำเตือนใด ๆ แต่ ping -s 2465 -c1 distrowatch.com ส่งคำเตือนนั่นหมายความว่า 2,464 + 28 เป็น MTU ที่ใหญ่ที่สุดที่ตั้งค่าคอนฟิก TCP / IP ของคุณสามารถจัดการได้ ก่อนที่จะส่งแพ็กเก็ตที่กระจัดกระจายหลายรายการ อาจใช้เวลาสักครู่เพื่อระบุค่าที่แน่นอน
เมื่อคุณคำนึงถึงคุณค่าจากการเรียกใช้คำสั่ง ping หลาย ๆ ครั้งคุณจะต้องเรียกใช้ sudo ifconfig เพื่อค้นหารายการอินเทอร์เฟซเครือข่ายที่รู้จัก Ubuntu และอนุพันธ์แฮ็กบัญชีรูท แต่เราดำเนินการจากเชลล์ที่สร้างโดย sudo bash สำหรับตัวอย่างของเรา ขอแนะนำให้คุณเพียงแค่นำหน้าแต่ละคำสั่งด้วย sudo ทีละคำสั่ง
ทันทีที่คุณรู้จักอุปกรณ์ที่ถูกต้องให้ลอง:
sudo ifconfig interfaceName man ####
แทนที่ interfaceName ด้วยชื่อของอะแดปเตอร์เครือข่ายที่คุณใช้งานจากนั้นแทนที่ #### ด้วยขนาดที่คุณพบบวก 28 สำหรับข้อมูลส่วนหัว คุณสามารถเรียกใช้ ifconfig เพื่อดูว่า MTU เริ่มต้นคืออะไรสำหรับ NIC ของคุณและเรียกใช้อีกครั้งหลาย ๆ ครั้งเพื่อดูว่าคำสั่งก่อนหน้านี้เปลี่ยนแปลงหรือไม่ อะแดปเตอร์อินเทอร์เฟซเครือข่ายบางตัวไม่ยอมให้คุณเปลี่ยน หากเป็นเช่นนั้นการเพิ่มประสิทธิภาพต่อไปจะไร้ผล อย่างไรก็ตามหากวิธีนี้ได้ผลคุณสามารถทำให้ถาวรได้จริง ลองวิ่ง ifconfig | grep MTU เพื่อค้นหาค่าทั้งหมดหากคุณมีตัวเชื่อมต่อหลายตัวจากนั้นคุณสามารถจับคู่ค่ากับตัวเชื่อมต่อที่คุณใช้งานได้
วิธีที่ 2: การสร้าง MTU Optimizations Stick
จนถึงตอนนี้คุณยังไม่ได้ทำการเปลี่ยนแปลงระบบของคุณอย่างถาวร หากคุณเริ่มต้นใหม่คุณจะล้างการเปลี่ยนแปลงใด ๆ ออกไปซึ่งเป็นการดีหากคุณทำผิดพลาดและพบว่าคุณไม่สามารถเชื่อมต่ออินเทอร์เน็ตได้อีกต่อไป ในทางกลับกันหากคุณพบค่าที่ถูกต้องสำหรับ MTU ของคุณคุณจะต้องแก้ไขไฟล์ 
เอกสาร. นี่อาจเป็นเวลาที่ดีที่จะทำสำเนาไว้เผื่อว่ามีอะไรเกิดขึ้น ลอง 
หรือสิ่งที่คล้ายกันเพื่อให้คุณมีสำเนาในกรณี หากคุณต้องการแก้ไขแบบกราฟิกให้พิมพ์ 
และป้อนรหัสผ่านของคุณ หากคุณใช้ Kubuntu, Xubuntu หรือ Lubuntu คุณจะต้องแทนที่ gedit ด้วยโปรแกรมแก้ไขข้อความแบบกราฟิกที่ Ubuntu ใช้งานได้ ตัวอย่างเช่น Xubuntu ใช้ mousepad แทน gedit หากคุณใช้ Ubuntu Server หรือต้องการทำงานกับบรรทัดคำสั่งให้พิมพ์แทน 
สมมติว่าคุณไม่ได้ใช้รูทเชลล์
ไม่ว่าคุณจะใช้วิธีใดในการแก้ไขให้ค้นหาชื่อของอินเทอร์เฟซ ifconfig ที่คายออกมาก่อน สมมติว่าคุณกำลังดูตัวเชื่อมต่อ Wifi แรกบนเครื่องของคุณซึ่งอาจใช้ชื่อว่า wlan0 หรืออะไรที่คล้ายกัน ในกรณีนี้ให้ค้นหาข้อมูลโค้ดที่ขึ้นต้นด้วย iface wlan0 inet static หรือสิ่งที่คล้ายกัน ระยะทางของคุณอาจแตกต่างกันไป แต่บรรทัดถัดไปจะอ่านที่อยู่ตามด้วยที่อยู่ IP ในรูปแบบ ###. ###. #. ## อาจมีรูปแบบที่แตกต่างออกไปหากคุณใช้การเชื่อมต่อ IPv6 แบบเนทีฟ คุณจะมีเน็ตมาสก์และเกตเวย์ตามด้วยรายการชื่อโฮสต์หรือชื่อที่คล้ายกัน ที่ด้านล่างคุณจะมีอีกบรรทัดหนึ่งที่อ่าน mtu และตัวเลข แทนที่ตัวเลขนั้นด้วยค่า Optimize MTU บันทึกเอกสารแล้วออกจากโปรแกรมแก้ไขข้อความ คุณจะต้องรีบูตระบบเพื่อให้แน่ใจว่าใช้งานได้
หากทุกอย่างเรียบร้อยดีหลังจากการรีบูตหลายครั้งให้ลบไฟล์ interface.bak ในไดเร็กทอรี ~ / Documents ของคุณ คุณสามารถใช้ sudo mv แทนได้ 
แล้ว
หากมีสิ่งผิดปกติในกระบวนการ
วิธีที่ 3: การแก้ไขการตั้งค่า TCP Receive Window (RWIN)
Ubuntu หมายถึงข้อมูลจำนวนมากที่สุดที่โฮสต์ยอมรับก่อนที่จะยอมรับว่าผู้ส่งเป็นค่า RWIN หากคุณดาวน์โหลดไฟล์ 30 MB เซิร์ฟเวอร์ระยะไกลจะไม่ส่งบล็อกข้อมูล 30 MB ให้คุณในทันที โฮสต์ Ubuntu ของคุณจะส่งหมายเลข RWIN เฉพาะเมื่อร้องขอไฟล์จากนั้นเซิร์ฟเวอร์จะเริ่มสตรีมข้อมูลจนกว่าจะครบจำนวนไบต์ก่อนที่จะรอการตอบรับว่าระบบของคุณได้รับข้อมูล เมื่อเซิร์ฟเวอร์ได้รับสิ่งนี้เซิร์ฟเวอร์จะเริ่มส่งบล็อกเพิ่มเติมก่อนที่จะรอการตอบรับอีกครั้ง
Latency คือเวลาที่ใช้ในการส่งและรับแพ็กเก็ตจากเซิร์ฟเวอร์ระยะไกล อัตราการเชื่อมต่อมีส่วนทำให้เกิดค่านี้ แต่ความล่าช้าอื่น ๆ ก็เช่นกัน คำสั่ง ping จะอธิบายเวลาแฝงในรูปของตัวเลขเวลาไปกลับ (RTT) ดูผลลัพธ์จากปิง DistroWatch ก่อนหน้าของเรา คุณจะพบบรรทัดที่อ่านว่า time = 134 ms ซึ่งเป็นระยะเวลาที่แพ็กเก็ตในการเดินทางไปกลับจากเครื่อง Ubuntu ไปยัง distrowatch.com และย้อนกลับมาอีกครั้ง เรากำลังส่งแพ็กเก็ต 1,492 ไบต์ดังนั้นที่ 134 มิลลิวินาทีเราสามารถคำนวณสูตรเพื่อหาความเร็วในการถ่ายโอนทั้งหมด:
1,492 / .134 วินาที = 11,134.328 ไบต์ / วินาทีซึ่งมีค่าประมาณ 10.88 ไบนารีกิโลไบต์ต่อวินาที โดยรวมแล้วค่อนข้างช้าซึ่งเป็นสาเหตุที่ RWIN ถูกนำมาใช้เพื่อป้องกันไม่ให้คุณต้องรับทราบแต่ละแพ็กเก็ตที่ส่งทีละรายการ
การตั้งค่า RWIN ใน Ubuntu แยกจากการตั้งค่า MTU คำนวณ Bandwidth Delay Product (BDP) สำหรับการเชื่อมต่ออินเทอร์เน็ตของคุณด้วยสูตรนี้:
(แบนด์วิดท์สูงสุดรวมที่การเชื่อมต่ออินเทอร์เน็ตของคุณควรจ่ายเป็นไบต์ต่อวินาที) (RTT in Seconds) = BDP
ขนาดแพ็กเก็ต TCP ไม่มีผลต่อ RWIN แต่ขนาดของแพ็กเก็ตเองจะได้รับอิทธิพลจากค่าที่เลือกในวิธีที่ 1 ใช้คำสั่งนี้เพื่อค้นหาตัวแปรเคอร์เนลที่เกี่ยวข้องกับ RWIN:
โปรดทราบว่ามีช่องว่างหลัง _mem แต่ไม่มีที่อื่นในข้อความที่ยกมา คุณจะได้รับค่าต่างๆกลับคืนมา สิ่งที่จำเป็นคือ net.ipv4.tcp_rmem, net.ipv4.tcp_wmem และ net.ipv4.tcp_mem . ตัวเลขหลังค่าเหล่านี้แสดงถึงค่าต่ำสุดค่าเริ่มต้นและค่าสูงสุดสำหรับแต่ละค่า แสดงเวกเตอร์หน่วยความจำหน้าต่างรับส่งเวกเตอร์และเวกเตอร์สแต็ก TCP หากคุณใช้ Ubuntu Kylin คุณอาจมีรายการเพิ่มเติมอีกมากมาย คุณสามารถละเว้นค่าเพิ่มเติมเหล่านี้ได้อย่างปลอดภัย ผู้ใช้ Kylin บางคนอาจเห็นค่าบางอย่างที่ระบุไว้ในสคริปต์อื่น ๆ แต่อีกครั้งเพียงแค่มองหาบรรทัดเหล่านี้
Ubuntu ไม่มีตัวแปร RWIN แต่ net.ipv4.tcp_rmem อยู่ใกล้ ตัวแปรเหล่านี้ควบคุมการใช้หน่วยความจำไม่ใช่แค่ขนาด TCP ซึ่งรวมถึงหน่วยความจำที่กินโดยโครงสร้างซ็อกเก็ตข้อมูลและแพ็กเก็ตสั้น ๆ ในบัฟเฟอร์ขนาดใหญ่ หากคุณต้องการปรับค่าเหล่านี้ให้เหมาะสมให้ส่งแพ็กเก็ตขนาดสูงสุดที่คุณตั้งไว้ในวิธีที่ 1 ไปยังเซิร์ฟเวอร์ระยะไกลอื่น ลองใช้ค่าเริ่มต้น 1,492 ไบต์อีกครั้งโดยลบ 28 ไบต์สำหรับข้อมูลส่วนหัว แต่อย่าลืมว่าคุณอาจมีค่าที่แตกต่างกัน ใช้คำสั่ง ping -s 1464 -c5 distrowatch.com เพื่อรับข้อมูล RTT เพิ่มเติม
คุณจะต้องทำการทดสอบนี้มากกว่าหนึ่งครั้งในเวลาที่ต่างกันของกลางวันและกลางคืน ลอง ping เซิร์ฟเวอร์ระยะไกลอื่น ๆ ด้วยเพื่อดูว่า RTT แตกต่างกันมากแค่ไหน เนื่องจากเรามีค่าเฉลี่ยมากกว่า 130 ms ในแต่ละครั้งที่เราทดลองใช้เราจึงสามารถใช้สูตรเพื่อหา BDP ของเราได้ สมมติว่าคุณใช้การเชื่อมต่อทั่วไป 6 Mbits / วินาที BDP จะเป็น:
(6,000,000 บิต / วินาที) (. 133 วินาที) * (1 ไบต์ / 8 บิต) = 99,750 ไบต์
ซึ่งหมายความว่าค่า net.ipv4.tcp_rmem เริ่มต้นควรอยู่ที่ประมาณ 100,000 คุณสามารถตั้งค่าให้สูงขึ้นได้หากคุณกลัวว่าจะได้รับ RTT ที่ไม่ดีภายในครึ่งวินาที ค่าทั้งหมดที่พบใน net.ipv4.tcp_rmem และ net.ipv4.tcp_wmem จะต้องตั้งค่าให้เหมือนกันเนื่องจากการส่งและรับแพ็กเก็ตเกิดขึ้นผ่านการเชื่อมต่ออินเทอร์เน็ตเดียวกัน โดยทั่วไปคุณจะต้องตั้งค่า net.ipv4.tcp_mem เป็นค่าเดียวกับที่ใช้โดย net.ipv4.tcp_wmem และ net.ipv4.tcp_rmem เนื่องจากตัวแปรแรกนี้เป็นขนาดหน่วยความจำบัฟเฟอร์ทั้งหมดที่ใหญ่ที่สุดที่กำหนดไว้สำหรับธุรกรรม TCP
ออกคำสั่ง 
และดูว่าการตั้งค่าทั้งสองนี้ถูกตั้งค่าเป็น 0 หรือ 1 ซึ่งแสดงสถานะปิดหรือเปิด
การตั้งค่า net.ipv4.tcp_no_metrics_save เป็น 1 จะบังคับให้เคอร์เนลของ Linux ปรับหน้าต่างการรับให้เหมาะสมระหว่างค่า net.ipv4.tcp_rmem และ net.ipv4.tcp_wmem ในรูปแบบไดนามิก เมื่อเปิดใช้ net.ipv4.tcp_moderate_rcvbuf จะป้องกันความแออัดไม่ให้มีผลต่อการเชื่อมต่อในภายหลัง ก่อนทำการเปลี่ยนแปลงถาวรใด ๆ ให้ทำการตรวจสอบความเร็วผ่าน http://www.speedtest.net หรือ http://www.bing.com/search?q=speed+test เพื่อให้แน่ใจว่าคุณมีส่วนควบคุมในการวัดของคุณ
เปลี่ยนตัวแปรชั่วคราวด้วยค่าที่คำนวณของคุณ อย่าลืมแทนที่ #s ด้วยผลรวมจากการคำนวณของคุณ
sudo sysctl -w net.ipv4.tcp_rmem =” #### ##### ###### 'net.ipv4.tcp_wmem =' #### ##### ###### ' net.ipv4.tcp_mem =” #### ##### ######” net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_moderate_rcvbuf = 1
ทดสอบการเชื่อมต่อของคุณอีกครั้งเพื่อดูว่าความเร็วดีขึ้นหรือไม่และหากไม่ปรับแต่งคำสั่งของคุณอีกครั้งและรันใหม่ โปรดจำไว้ว่าคุณสามารถกดปุ่มขึ้นในเทอร์มินัลเพื่อทำซ้ำคำสั่งที่ใช้ล่าสุด เมื่อคุณพบค่าที่เหมาะสมแล้วให้เปิด 
กับ gksu หรือ sudo คำสั่งแก้ไขข้อความจากวิธีที่ 1 และแก้ไขบรรทัดที่จะอ่านดังต่อไปนี้อีกครั้งแทนที่ #s ด้วยค่าที่คำนวณของคุณ แน่นอนคุณจะต้องสำรองข้อมูลไฟล์ 
ยื่นแบบเดียวกับที่คุณทำในส่วนที่หนึ่งในกรณีที่คุณทำผิดพลาด หากคุณสร้างขึ้นมาคุณก็สามารถกู้คืนในรูปแบบเดียวกันได้เช่นกัน
net.ipv4.tcp_rmem = #### ##### ######
net.ipv4.tcp_wmem = #### ##### ######
net.ipv4.tcp_mem = #### ##### ######
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
บันทึกไว้เมื่อคุณแน่ใจว่าทุกอย่างเรียบร้อย ออกคำสั่งต่อไปนี้:
sudo sysctl -p
สิ่งนี้จะบังคับให้เคอร์เนล Linux โหลดการตั้งค่าซ้ำใน 
และถ้าทุกอย่างเป็นไปด้วยดีก็ควรให้การเชื่อมต่อเครือข่ายที่เร็วกว่านี้เป็นอย่างน้อย ขึ้นอยู่กับค่าเริ่มต้นเดิมของคุณความแตกต่างอาจเป็นอย่างมากหรืออาจไม่สามารถสังเกตเห็นได้เลย
