ฉันใช้งาน VM หลายเครื่องใน Azure VMs กำลังทำงานในเครือข่ายย่อยด้วย NSG NIC ไม่ใช้ NSG เราไม่ใช้เครือข่ายเร่งความเร็ว

ฉันสังเกตเห็นว่าเมื่อ VM พูดคุยกับ VM อื่นของซับเน็ตเดียวกันโดยใช้ TCP ค่า MSS ในแพ็กเก็ต SYN จะลดลง 42 นั่นหมายความว่าถ้าฉันส่ง TCP SYN ที่มี MSS=876 ไปยัง VM อื่นของเครือข่ายเดียวกัน VM อื่นจะจับ TCP SYN ด้วย MSS=834:

ลูกค้า:

18:49:27.526527 IP 10.56.142.25.49614 > 10.56.142.108.ssh: ค่าสถานะ [S], seq 3092614737, ชนะ 17520, ตัวเลือก [mss 876,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], ความยาว 0
18:49:27.528398 IP 10.56.142.108.ssh > 10.56.142.25.49614: ค่าสถานะ [S.], seq 1710658781, ack 3092614738, ชนะ 28960, ตัวเลือก [mss 1418,sackOK,TS val 390195731,ecnop 2423,wop 2423,wop2731 ], ความยาว 0
18:49:27.528430 IP 10.56.142.25.49614 > 10.56.142.108.ssh: ค่าสถานะ [.], ack 1, ชนะ 137, ตัวเลือก [nop,nop,TS val 2936204425 ecr 390195731], ความยาว 0

เซิร์ฟเวอร์:

18:49:27.527362 IP 10.56.142.25.49614 > 10.56.142.108.ssh: ค่าสถานะ [S], seq 3092614737, ชนะ 17520, ตัวเลือก [mss 834,sackOK,TS val 2936204423 ecr 0,nop,wscale 7], ความยาว 0
18:49:27.527682 IP 10.56.142.108.ssh > 10.56.142.25.49614: แฟล็ก [S.], seq 1710658781, ack 3092614738, win 28960, options [mss 1460,sackOK,TS val 390195731,ecnop 2426,wop 2423,wop 2423 ], ความยาว 0
18:49:27.529167 IP 10.56.142.25.49614 > 10.56.142.108.ssh: ค่าสถานะ [.], ack 1, ชนะ 137, ตัวเลือก [nop,nop,TS val 2936204425 ecr 390195731], ความยาว 0

เรากำลังใช้ NVA หลายตัว และแพ็กเก็ต SYN ของเราเดินทางผ่านหลายฮอป และเราเห็นว่า MSS ลดลงหลายครั้ง เดิมทีเราวัดการลดลงได้ 84 เรายังวัดการลดลงได้ 138 ในบางกรณี (อันที่จริงไม่ใช่ผลคูณของ 42) นั่นหมายความว่าเราลดประสิทธิภาพของเครือข่ายลงมากกว่า 10%

ฉันได้ใช้เวลาพิจารณาว่าอุปกรณ์เครือข่ายต่างๆ เล่นกับ MSS อย่างไร ในกรณีส่วนใหญ่ MSS ถูกกำหนดเป็นจำนวนคงที่ โดยยึดเป็นค่าคงที่หรือตามเส้นทาง MTU PaloAlto จะใช้ "การปรับค่า" ที่สัมพันธ์กับ MTU ของอินเทอร์เฟซเครือข่าย ซึ่งเป็นค่าคงที่ Arista จะให้คุณกำหนดค่าเพดานในการรับส่งข้อมูลขาเข้าหรือขาออก ซึ่งเป็นค่าสัมบูรณ์อีกครั้ง ผู้จำหน่ายไฟร์วอลล์บางราย เช่น PaloAlto จะลด MSS ในกรณีที่มีการโจมตี DoS และเปิดใช้งานคุกกี้ SYN แต่ MSS จะเป็นหนึ่งใน 8 ค่าที่เป็นไปได้ในกรณีนั้น

ฉันเชื่อว่ากลไก MSS -= 42 นี้ทำลาย TCP: หากไคลเอนต์รองรับเฟรมจัมโบ้และส่ง MSS 8860 เซิร์ฟเวอร์ใน Azure ได้รับ 8876 ตัวมันเองตอบกลับ 1330 แต่ไคลเอ็นต์ได้รับ 1246 ไคลเอนต์จะยอมรับว่าแพ็กเก็ตควรมี 1246 ไบต์ payload ในขณะที่เซิร์ฟเวอร์จะส่ง payload 1330 ไบต์

ปัญหาที่ใหญ่ที่สุดคือเรามีกรณีที่การจราจรทำงาน "โดยบังเอิญ"การหนีบไม่ได้ทำอย่างถูกต้องบนฝั่งของเส้นทางด่วน แต่ด้วยเหตุนี้ -42 ที่นี่และที่นั่น MSS จึงลดลงเป็นค่าที่ "เหมาะสม" จริง ๆ จนกว่าจะมีการเปลี่ยนแปลงเล็กน้อยในเส้นทางแพ็กเก็ต และคุณพบว่า ทันใดนั้นก็มีการกำหนดค่าผิดพลาดที่ไหนสักแห่ง

มีความคิดว่าจะอธิบายการลดลงนี้อย่างไร ฉันเชื่อว่าพฤติกรรมนี้ไม่ได้บันทึกไว้ทุกที่

แก้ไข

แค่อ่าน RFC879

สามารถใช้ MSS ได้อย่างอิสระในแต่ละทิศทางของการไหลของข้อมูล ผลลัพธ์อาจมีขนาดสูงสุดที่แตกต่างกันมากในสองทิศทาง

ดังนั้นจึงดูถูกต้องตาม RFC ถึงกระนั้นพฤติกรรมแปลก ๆ