คำถามติดแท็ก tcp

เซิร์ฟเวอร์ linux ของฉันกำลังพยายามสร้างการเชื่อมต่อ LDAPS ไปยังเซิร์ฟเวอร์แคตตาล็อกส่วนกลางและการเชื่อมต่อเริ่มลดลง สำหรับวัตถุประสงค์ของการสนทนาสมมติว่า 1.1.1.1 เป็นเซิร์ฟเวอร์ Linux และ 1.2.3.4 เป็นเซิร์ฟเวอร์แค็ตตาล็อกส่วนกลาง ถ้าฉันพยายามใช้telnetจากกล่อง Linux ฉันเห็น: [root@foobox ~]# telnet gcfoo.exampleAD.local 3269 Trying 1.2.3.4... Connected to gcfoo.examplead.local. Escape character is '^]'. Connection closed by foreign host. ไม่มีความล่าช้าระหว่างบรรทัดที่ 4 และ 5 มันลดการเชื่อมต่อทันที ฉันคิดว่าtelnetผลลัพธ์อาจทำให้เข้าใจผิดเล็กน้อย (เนื่องจากมันไม่เหมาะสำหรับการสื่อสารที่ปลอดภัยประเภทใด ๆ ) ดังนั้นฉันจึงรวบรวมแพคเก็ตของการพยายามเชื่อมต่อจริงจากอุปกรณ์ (ใช้โปรแกรมจริงที่ต้องใช้ LDAPS) นี่คือสิ่งที่ฉันเห็น (อีกครั้ง IP และพอร์ตต้นทางได้รับการเปลี่ยนชื่อเพื่อปกป้องผู้บริสุทธิ์): …

14 ldap  tcp  tcpip 

ฉันต้องการมีซ็อกเก็ตโดเมน UNIX เช่น /var/program/program.cmd ตัวอย่างเช่นเปิดเผยผ่าน TCP ให้พูดที่พอร์ต 12345 นอกจากนี้ฉันยังต้องการให้ทำงานเต็มเวลาในพื้นหลัง วิธีที่ดีที่สุดในการทำเช่นนี้คืออะไร? ถ้ามันเกี่ยวข้องระบบกำลังใช้งาน Ubuntu 12.04.2 นอกจากนี้ยังมีโซลูชันที่เสนอจะอยู่รอดได้ในซ็อกเก็ตโดเมนที่ถูกลบและสร้างใหม่? แก้ไข นี่คือผลลัพธ์ของคำตอบที่ยอมรับในรูปแบบของสคริปต์เริ่มต้น: https://github.com/Wirehive/haproxy-remote

14 linux  ubuntu  tcp  socket 

ฉันสังเกตเห็นว่าบางครั้งขณะพยายาม telnet ในพอร์ตสุ่มบางอย่างฉันได้สังเกตสถานการณ์สองชนิด: $ telnet example.com 3432 Trying 173.252.110.27... $ telnet example.com 3432 Connection Refused. ใครสามารถอธิบายฉันว่าอะไรคือความแตกต่างระหว่างสองอย่างนี้?

14 networking  tcp 

ฉันใช้ระบบ CentOS 6.7 (Final) และเมื่อฉันพยายามเรียกใช้ncในโหมดฟังมันจะพิมพ์ข้อมูลต่อไปนี้: # nc -l 1234 nc: Protocol not available พอร์ตไม่ถูกผูกไว้ ฉันลองหมายเลขพอร์ตอื่นด้วย ข้อผิดพลาดนี้ดูเหมือนจะได้รับรายงานแล้ว: https://access.redhat.com/solutions/1753753 น่าเสียดายที่มันไม่ได้มีรายละเอียดมาก ข้อมูลแพ็คเกจ: Name : nc Arch : x86_64 Version : 1.84 Release : 24.el6 มีอะไรอีกบ้างที่ฉันต้องลอง

13 linux  centos  tcp  netcat 

Wireshark | ของ windows ฉันต้องการค้นหาการรับส่งข้อมูลแพ็กเก็ตของ SMTP สำหรับที่อยู่ / ข้อความเฉพาะ โดยปกติแล้วฉันจะเรียงลำดับคอลัมน์ข้อมูลและเรียกดู แต่มันจะดีถ้าฉันสามารถเรียกใช้การค้นหาหรือตัวกรองสำหรับสตริงเฉพาะที่ฉันกำลังมองหา มีวิธีการทำเช่นนี้ใน Wireshark หรือไม่?

13 tcp  wireshark  packet-analyzer  packet-capture 

ฉันมีโทโพโลยีสะพานคู่แบบอสมมาตรตามที่แสดงด้านล่างเมื่อฉันเชื่อมต่อจาก 172.16.11.5 และ 172.16.10.6 ด้วย ssh แต่ฉันไม่สามารถเชื่อมต่อได้เนื่องจาก SynProxy ------- | | ---o--- 172.16.11.5 | | -----o----- 172.16.11.6 | | | | default gw 1.1.1.1 | | 1.1.1.2/30 --o----o--- 2.2.2.2/30 | | | | | | (enp10s0f0) ----o----o----- | | | XXX | | | | br1 br0 | synproxy | …

12 linux  linux-networking  tcp  tcpdump 

เรามีแอปพลิเคชั่นเซิร์ฟเวอร์ที่กำลังประสบปัญหาการเชื่อมต่อ TCP ที่ประมาณ 4000 การเชื่อมต่อ สิ่งนี้จะเกิดขึ้นทุก 3 หรือ 4 สัปดาห์ (โดยประมาณ) ผู้ขายซึ่งได้สร้างแอปพลิเคชันเซิร์ฟเวอร์นี้จะบอกเราหลังจากตรวจสอบเอาต์พุตของ netstat -b ว่าการเชื่อมต่อบางส่วนยังคงเปิดอยู่แม้ว่าลูกค้าจะหลุด ฉันได้รับมอบหมายให้ทำการตรวจสอบว่าเหตุใดแอปพลิเคชันไคลเอนต์บางตัวจึงไม่ปิดการเชื่อมต่อ TCP อย่างถูกต้อง ฉันเชื่อว่าหากคอมพิวเตอร์ไคลเอนต์ปิดตัวลงก็ไม่สามารถรายงาน POSSIBLY จากเซิร์ฟเวอร์ที่ยังคงมีการเชื่อมต่อ TCP กับไคลเอนต์นั้น น่าเสียดายที่ฉันไม่พบข้อมูลใด ๆ เพื่อตรวจสอบมุมมองของฉัน ฉันไม่ต้องการเสียเวลาตรวจสอบปัญหาที่อาจเกิดขึ้นซึ่งฉันไม่คิดว่าจะเป็นปัญหาได้อีกต่อไป TLDR; เซิร์ฟเวอร์สามารถรายงานการเชื่อมต่อที่สร้างไว้กับคอมพิวเตอร์ที่ปิดอยู่ได้หรือไม่?

12 windows-server-2008  tcp 

ฉันจะค้นหาที่อยู่ MAC ของเครื่องในเครือข่ายได้อย่างไร ฉันต้องการค้นหาเครื่องที่มีเฉพาะเมื่อติดตั้ง BIOS เท่านั้น (ไม่มีระบบปฏิบัติการ) และฉันต้องการค้นหาที่อยู่ MAC ของเครื่องที่อัพ

12 networking  tcp  bios  mac-address 

ฉันกำลังตรวจสอบ TCP สแต็กบนเซิร์ฟเวอร์หวังว่าจะอนุมานปัญหาทั่วไปเกี่ยวกับแอปพลิเคชันในกล่อง ความโน้มเอียงแรกของฉันคือการวัดจำนวนซ็อกเก็ตในทุกสถานะที่รายงาน (LISTEN, ESTABLISHED, FIN_WAIT2, TIME_WAIT ฯลฯ ) และตรวจสอบความผิดปกติบางอย่าง เพื่อนร่วมทีมแนะนำว่า 'lsof' จะเป็นเครื่องมือที่ดีกว่าในการดูว่าสแต็ก TCP อยู่ในสถานะใด การตั้งค่าหรือเคล็ดลับประสบการณ์จากฝูงชน serverfault หรือไม่

12 linux  unix  tcp  netstat  lsof 

ล็อคแล้ว คำถามและคำตอบของคำถามนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ เป็นงานทั่วไปในการตรวจสอบ 'คุณภาพ' ของเครือข่าย - เวลาแฝง, จำนวนแพ็คเก็ตที่ถูกทิ้ง ฯลฯ แต่ 'ping' มีจำนวนข้อเสีย: - ใช้ ICMP ISP หลายรายมี shapers ที่แตกต่างกันสำหรับการรับส่งข้อมูล ICMP และ TCP ดังนั้น 'ping' จะแสดงเวลาแฝง 10ms แต่การเชื่อมต่อ TCP จะได้รับ 1,000ms + - ส่งแพ็คเก็ตจำนวนน้อยมาก โดยค่าเริ่มต้นหนึ่งแพ็คเก็ตทุกวินาที เนื่องจากโปรโตคอล TCP ทนต่อการสูญเสียแพ็กเก็ต (สามารถทำงานได้ดีมากคือแพ็คเก็ตครึ่งหนึ่งหายไป - เป็นเรื่องปกติ) จึงไม่ชัดเจนหากการเชื่อมต่อการฆ่า "30% แพ็กเก็ตสูญเสีย" ของปิงหรือถ้าเป็นเรื่องปกติ ดังนั้นมันเป็นทางเลือกสำหรับ ping ที่ใช้การเชื่อมต่อ TCP …

12 networking  tcp 

ฉันมีกฎ iptables จำนวนหนึ่งในไฟร์วอลล์ของฉันที่มีลักษณะดังนี้: iptables -A zone_lan_forward -p tcp -d 1.2.3.0/24 -j ACCEPT iptables -A zone_lan_forward -p udp -d 1.2.3.0/24 -j ACCEPT มีทางลัดสำหรับการมีกฎสองข้อ - กฎข้อหนึ่งสำหรับ tcp และอีกอันสำหรับ udp - สำหรับทุกที่อยู่? ฉันหมายถึงฉันสามารถทำสิ่งนี้: iptables -A zone_lan_forward -p tcp,udp -d 1.2.3.0/24 -j ACCEPT

12 iptables  firewall  tcp  udp 

ฉันมีปัญหาในกระบวนการระยะยาวที่เรียกว่าKube-พร็อกซี่เป็นส่วนหนึ่งของKubernetes ปัญหาคือบางครั้งการเชื่อมต่อที่เหลืออยู่ในสถานะ FIN_WAIT2 $ sudo netstat -tpn | grep FIN_WAIT2 tcp6 0 0 10.244.0.1:33132 10.244.0.35:48936 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:48340 10.244.0.35:56339 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:52619 10.244.0.35:57859 FIN_WAIT2 14125/kube-proxy tcp6 0 0 10.244.0.1:33132 10.244.0.50:36466 FIN_WAIT2 14125/kube-proxy การเชื่อมต่อเหล่านี้สแต็คเมื่อเวลาผ่านไปทำให้กระบวนการทำงานผิดปกติ ฉันรายงานปัญหาไปยังตัวติดตามข้อบกพร่องของ Kubernetes แล้ว แต่ฉันต้องการที่จะเข้าใจว่าทำไมการเชื่อมต่อดังกล่าวจึงไม่ถูกปิดโดยเคอร์เนล Linux ตามเอกสาร (การค้นหา tcp_fin_timeout) การเชื่อมต่อในสถานะ FIN_WAIT2 ควรปิดโดยเคอร์เนลหลังจาก …

11 linux-networking  tcp  kernel  connection 

ฉันรู้ว่ามีคำถาม SE ค่อนข้างน้อยเกี่ยวกับเรื่องนี้และฉันเชื่อว่าฉันอ่านมากเท่าที่มันสำคัญก่อนที่จะมาถึงจุดนี้ โดย "ฝั่งเซิร์ฟเวอร์TIME_WAIT" ฉันหมายถึงสถานะของคู่ซ็อกเก็ตฝั่งเซิร์ฟเวอร์ที่มีการปิด () เริ่มต้นที่ฝั่งเซิร์ฟเวอร์ ฉันมักจะเห็นข้อความเหล่านี้ที่ขัดแย้งกับฉัน: ฝั่งเซิร์ฟเวอร์TIME_WAITไม่เป็นอันตราย คุณควรออกแบบแอปเครือข่ายของคุณเพื่อให้ไคลเอนต์เริ่มต้นปิด () ดังนั้นให้ลูกค้ารับ TIME_WAIT เหตุผลที่ฉันพบข้อขัดแย้งนี้เป็นเพราะTIME_WAITในไคลเอนต์อาจมีปัญหา - ลูกค้าสามารถเรียกใช้จากพอร์ตที่มีอยู่ดังนั้นในสาระสำคัญข้างต้นจะแนะนำให้ย้ายภาระของTIME_WAITไปยังฝั่งไคลเอ็นต์ซึ่งอาจเป็นปัญหาจาก ฝั่งเซิร์ฟเวอร์ที่ไม่มีปัญหา TIME_WAITแน่นอนว่าลูกค้าฝั่งนั้นมีปัญหาเฉพาะกรณีใช้งานในจำนวนที่ จำกัด โซลูชันไคลเอนต์เซิร์ฟเวอร์ส่วนใหญ่จะเกี่ยวข้องกับเซิร์ฟเวอร์เดียวและไคลเอนต์จำนวนมากลูกค้ามักจะไม่จัดการกับการเชื่อมต่อในปริมาณมากพอที่จะเป็นปัญหาและแม้ว่าพวกเขาจะทำมีคำแนะนำจำนวนมากให้ "sanely" ( เมื่อเทียบSO_LINGERกับการหมดเวลา 0 หรือยุ่งกับ tcp_tw sysctls) ต่อสู้ฝั่งไคลเอ็นต์TIME_WAITโดยหลีกเลี่ยงการสร้างการเชื่อมต่อมากเกินไปเร็วเกินไป แต่นั่นไม่ได้เป็นไปได้เสมอตัวอย่างเช่นคลาสของแอปพลิเคชันเช่น: ระบบตรวจสอบ เครื่องกำเนิดไฟฟ้าโหลด ผู้รับมอบฉันทะ ในอีกด้านฉันไม่เข้าใจด้วยซ้ำว่าฝั่งเซิร์ฟเวอร์TIME_WAITมีประโยชน์อย่างไร เหตุผลTIME_WAITก็คือแม้จะมีเพราะมันช่วยป้องกันการฉีดTCPชิ้นส่วนเก่าค้างในกระแสที่พวกเขาไม่ได้เป็นของอีกต่อไป สำหรับฝั่งไคลเอ็นต์TIME_WAITมันสามารถทำได้โดยเพียงทำให้เป็นไปไม่ได้ที่จะสร้างการเชื่อมต่อกับip:portคู่เดียวกันกับที่การเชื่อมต่อเก่านี้อาจมี (คู่ที่ใช้ถูกล็อคโดยTIME_WAIT) แต่สำหรับฝั่งเซิร์ฟเวอร์สิ่งนี้ไม่สามารถป้องกันได้เนื่องจากที่อยู่ในท้องถิ่นจะมีพอร์ตที่ยอมรับและจะเหมือนกันเสมอและเซิร์ฟเวอร์ไม่สามารถ (AFAIK ฉันมีหลักฐานเชิงประจักษ์เท่านั้น) ปฏิเสธการเชื่อมต่อเพียงเพราะ เพียร์ที่เข้ามาจะสร้างคู่ที่อยู่เดียวกันที่มีอยู่แล้วในตารางซ็อกเก็ต ฉันเขียนโปรแกรมที่แสดงว่าเซิร์ฟเวอร์จะไม่สนใจ TIME-WAIT ยิ่งกว่านั้นเนื่องจากการทดสอบเสร็จสิ้นใน 127.0.0.1 เคอร์เนลจะต้องมีบิตพิเศษที่จะบอกว่าเป็นฝั่งเซิร์ฟเวอร์หรือฝั่งไคลเอ็นต์ (เนื่องจากมิฉะนั้น tuple จะเหมือนกัน) …

11 tcp 

ฉันมีกล่อง linux ที่ฉันใช้เป็นiperf3ไคลเอนต์ทดสอบกล่องเซิร์ฟเวอร์ Windows 2012 R2 2 ตัวที่ติดตั้งมาพร้อมกับ Broadcom BCM5721, อะแดปเตอร์ 1Gb (2 พอร์ต แต่ใช้เพียง 1 พอร์ตสำหรับการทดสอบ) เครื่องทั้งหมดเชื่อมต่อกันด้วยสวิตช์ 1Gb เพียงตัวเดียว ทดสอบ UDP ที่เช่น 300Mbit iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192 ส่งผลให้สูญเสีย 14% ของแพ็กเก็ตทั้งหมดที่ส่ง (สำหรับกล่องเซิร์ฟเวอร์อื่นที่มีฮาร์ดแวร์เดียวกันแน่นอน แต่ไดรเวอร์ NIC รุ่นเก่าสูญเสียประมาณ 2%) แต่การสูญเสียเกิดขึ้นแม้ที่ 50Mbit แม้ว่าจะรุนแรงน้อยกว่าก็ตาม ประสิทธิภาพ TCP โดยใช้การตั้งค่าที่เทียบเท่า: iperf3 -ZVc 192.168.30.161 -t5 --get-server-output …

11 performance  tcp  udp  packetloss  iperf 

ฉันมีเซิร์ฟเวอร์ที่มีการเชื่อมต่อ 10GbE ไปยังสวิตช์และลูกค้า 10 รายที่มีการเชื่อมต่อ 1GbE ไปยังสวิตช์เดียวกัน ใช้ nuttcp แบบขนานบนไคลเอนต์แต่ละตัวฉันสามารถส่งข้อมูล TCP 10 สตรีมไปยังเซิร์ฟเวอร์พร้อมกันที่ความเร็วสายไฟ (เช่นเพียงแค่ขี้อาย 100 เมกะไบต์ต่อวินาทีจากไคลเอนต์ทั้ง 10 พร้อมกัน) อย่างไรก็ตามเมื่อฉันย้อนกลับทิศทางและส่งข้อมูลจากเซิร์ฟเวอร์ไปยังไคลเอนต์ - นั่นคือ 10 TCP สตรีมหนึ่งคนไปยังไคลเอนต์แต่ละคน - TCP retransmissions skyrocket และประสิทธิภาพลดลงถึง 30, 20 หรือแม้แต่ 10 เมกะไบต์ต่อวินาที ต่อลูกค้าหนึ่งราย ฉันต้องการทำให้ตัวเลขเหล่านี้สูงขึ้นเนื่องจากรูปแบบการรับส่งข้อมูลนี้เป็นตัวแทนของแอปพลิเคชันบางอย่างที่ฉันสนใจ ฉันได้ตรวจสอบแล้วว่าเซิร์ฟเวอร์ของฉันสามารถเชื่อมโยงลิงค์ 10GbE ด้วยการทดสอบเดียวกันผ่านการเชื่อมต่อ 10GbE กับเซิร์ฟเวอร์ที่คล้ายกัน ฉันได้ตรวจสอบแล้วว่าไม่มีข้อผิดพลาดในพอร์ตใด ๆ ของฉัน ในที่สุดเมื่อฉันบังคับกวาด (จำกัด ) ขนาดหน้าต่าง TCP ของผู้รับฉันสามารถรับแบนด์วิดท์ได้ค่อนข้างสูง …

11 linux  networking  tcp