কোনও সার্ভার কেন একটি এসওয়াইএন প্যাকেটের প্রতিক্রিয়াতে একটি এসওয়াইএন / এসি প্যাকেট প্রেরণ করবে না

Question

ইদানীং, আমরা একটি টিসিপি সংযোগ সমস্যা সম্পর্কে সচেতন হয়েছি যা বেশিরভাগ ম্যাক এবং লিনাক্স ব্যবহারকারীদের মধ্যে সীমাবদ্ধ যারা আমাদের ওয়েবসাইটগুলি ব্রাউজ করে।

ব্যবহারকারীর দৃষ্টিকোণ থেকে, এটি আমাদের ওয়েবসাইটগুলিতে (> ১১ সেকেন্ড) সত্যিই দীর্ঘ সংযোগের সময় হিসাবে নিজেকে উপস্থাপন করে।

আমরা এই সমস্যার প্রযুক্তিগত স্বাক্ষর সন্ধান করতে পেরেছি, তবে কেন এটি হচ্ছে বা কীভাবে এটি ঠিক করা যায় তা নির্ধারণ করতে পারি না।

মূলত, যা ঘটছে তা হ'ল ক্লায়েন্টের মেশিনটি টিসিপি সংযোগ স্থাপনের জন্য এসওয়াইএন প্যাকেট প্রেরণ করছে এবং ওয়েব সার্ভার এটি গ্রহণ করে, তবে এসওয়াইএন / এসিকে প্যাকেটের সাথে সাড়া দেয় না। ক্লায়েন্ট অনেকগুলি এসওয়াইএন প্যাকেট প্রেরণের পরে, সার্ভারটি শেষ পর্যন্ত একটি এসওয়াইএন / এসিকে প্যাকেটের সাথে সাড়া দেয় এবং সংযোগের বাকী অংশগুলির জন্য সবকিছু ঠিক আছে।

এবং, অবশ্যই সমস্যার মূল কারণ: এটি মাঝে মাঝে চলে এবং এটি সর্বদা ঘটে না (যদিও এটি সময়ের দশ থেকে ৩০% এর মধ্যে ঘটে)

আমরা ফেডোরা 12 লিনাক্সকে ওএস হিসাবে এবং এনগিনেক্সকে ওয়েব সার্ভার হিসাবে ব্যবহার করছি।

ওয়্যারশার্ক বিশ্লেষণের স্ক্রিনশট

হালনাগাদ:

ক্লায়েন্টের উইন্ডো স্কেলিং বন্ধ করে দেওয়া সমস্যাটি থামিয়ে দেয়। এখন আমার কেবল একটি সার্ভার সাইড রেজোলিউশন দরকার (আমরা সমস্ত ক্লায়েন্টকে এটি করতে পারি না) :)

চূড়ান্ত আপডেট:

সমাধানটি ছিল জনসাধারণের জন্য অ্যাক্সেসযোগ্য আমাদের সার্ভারগুলিতে টিসিপি উইন্ডো স্কেলিং এবং টিসিপি টাইমস্ট্যাম্প উভয়ই বন্ধ করে দেওয়া ।

Comments

আমি মনে করি এটির কিছু টিসিপিডাম্প আমাদের দেখতে হবে।

— coredump

বিপরীত ডিএনএসের উপর ভিত্তি করে আপনার কি কোনও acls বা নিয়ম আছে? ক্লায়েন্ট এবং সার্ভারের মধ্যে কেবল সংযোগের পরে আপনাকে আরও দেখার প্রয়োজন হতে পারে। সম্ভবত কোনও ডিএনএস লুক্কায়নের সময় শেষ হচ্ছে?

— জোরেডেচ

@ কর্ডম্প্প: এখানে ওয়্যারশার্ক বিশ্লেষণের একটি স্ক্রিন শট দেওয়া হয়েছে যা এই সমস্যাটি দেখায় i.imgur.com/Bnzrm.png (কীভাবে কেবল স্রোত রফতানি করতে পারি তা বুঝতে পারিনি ....)

— কোডমোনকি

@ জোরেদাছে: না, বিপরীত ডিএনএসের ভিত্তিতে আমাদের কোনও অ্যাকসিল বা নিয়ম নেই। এটি একটি সর্বজনীন মুখোমুখি ওয়েবসার্ভার এবং আমরা প্রত্যেককে এটি অ্যাক্সেস করার অনুমতি দিই

— কোডমোনকি

কেবল একটি কুঁচক, তবে আপনি সার্ভারে কোনও ধরণের আগমন সংযোগ রেট-সীমাবদ্ধ করছেন? বলুন, আইপটিবল দিয়ে?

— স্টিভেন সোমবার

Answer 1

আমাদের ঠিক একই সমস্যা ছিল। কেবলমাত্র টিসিপি টাইমস্ট্যাম্পগুলি অক্ষম করা সমস্যার সমাধান করেছে।

sysctl -w net.ipv4.tcp_timestamps=0

এই পরিবর্তনটি স্থায়ী করতে, একটি এন্ট্রি করুন /etc/sysctl.conf।

টিসিপি উইন্ডো স্কেল বিকল্পটি অক্ষম করার বিষয়ে খুব সাবধান হন। ইন্টারনেটে সর্বাধিক পারফরম্যান্স সরবরাহের জন্য এই বিকল্পটি গুরুত্বপূর্ণ is 10 মেগাবিট / সেকেন্ড সংযোগযুক্ত কারও যদি রাউন্ড ট্রিপ সময় (মূলত পিংয়ের সমান) 55 এমএসের বেশি হয় তবে সাব-থিমাল ট্রান্সফার করতে হবে ।

একই NAT এর পিছনে একাধিক ডিভাইস থাকা অবস্থায় আমরা সত্যিই এই সমস্যাটি লক্ষ্য করেছি। আমি সন্দেহ করি যে টাইমস্ট্যাম্প ক্ষেত্রগুলিতে সম্পূর্ণ ভিন্ন মান রেখে তারা সার্ভার একই সাথে অ্যান্ড্রয়েড ডিভাইস এবং ওএসএক্স মেশিনের টাইমস্ট্যাম্পগুলি দেখে বিভ্রান্ত হয়ে থাকতে পারে।

Comments

কেস অন্য কেউ একই শশকের গর্ত মাধ্যমে এখানে আমি শুধু গেলেন প্রান্ত ইন: আগে বিভিন্ন TCP বন্ধ করে রাখলে টাইমস্ট্যাম্প বা উইন্ডো স্কেলিং, যা একটি উচ্চ ট্রাফিক লিঙ্কে তীব্র কর্মক্ষমতা ফল হতে পারে, যদি tcp_tw_recycle আপনার সমস্যা রয়েছে কিনা তা পরীক্ষা: Stackoverflow .কম / প্রশ্ন / 8893888 /…

— নেফেটস

Answer 2

আমার ক্ষেত্রে নিম্নলিখিত কমান্ডটি লিনাক্স সার্ভার থেকে পাওয়া অনুপস্থিত SYN / ACK জবাবগুলির সাথে সমস্যার সমাধান করেছে:

sysctl -w net.ipv4.tcp_tw_recycle=0

আমি মনে করি এটি টিসিপি টাইমস্ট্যাম্পগুলি অক্ষম করার চেয়ে বেশি সঠিক, কারণ টিসিপি টাইমস্ট্যাম্পগুলি উচ্চ পারফরম্যান্সের জন্য দরকারী (PAWS, উইন্ডো স্কেলিং ইত্যাদি)।

tcp_tw_recycleস্পষ্টভাবে ডকুমেন্টেশনটিতে বলা হয়েছে যে এটি সক্ষম করার জন্য এটি সুপারিশ করা হয় না, কারণ অনেকগুলি নেট রাউটার টাইমস্ট্যাম্প সংরক্ষণ করে এবং একইভাবে পিএডাব্লুএস কিক ইন করে, কারণ একই আইপি থেকে টাইমস্ট্যাম্পগুলি সামঞ্জস্যপূর্ণ নয়।

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.

Comments

এখানে ভাল ব্যাখ্যা: vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux সার্ভার সাইডে, নেট.আইপিভি 4.tcp_tw_re سائیکل সক্ষম করবেন না যদি না আপনি নিশ্চিত হন যে আপনার কাছে কখন না নেট ডিভাইস থাকবে না দ্রবণে.

— জেনেছিলেন

আমার ক্ষেত্রে, net.ipv4.tcp_tw_recycleআসল কারণ। ধন্যবাদ।

— ব্লুয়ারো

tcp_tw_recycle সাম্প্রতিক কার্নেলগুলিতে সরানো হয়েছে। একইভাবে আর কি সমাধান আছে? @ নেফিটস বোঝায় যে টাইমস্ট্যাম্প অক্ষম করা পারফরম্যান্সকে আঘাত করে।

— ম্যাপাপাম

যেহেতু tcp_tw_reयकल সরানো হয়েছে তাই সমস্যাটি আর দেখা উচিত নয় কারণ এটি কেবলমাত্র tcp_tw_reयकल এর একটি অ-ডিফল্ট মান নিয়ে ঘটেছিল।

— ল্যাভ

Answer 3

কেবল ভাবছি, তবে কেন এসওয়াইএন প্যাকেটটির জন্য (ফ্রেম # 539; যেটি গৃহীত হয়েছিল), ডাব্লুএস এবং টিএসভি ক্ষেত্রগুলি "তথ্য" কলামে অনুপস্থিত?

ডাব্লুএস টিসিপি উইন্ডো স্কেলিং এবং টিএসভি হ'ল টাইমস্ট্যাম্প মান । তারা উভয়ই tcp.options ফিল্ডের অধীনে পাওয়া যায় এবং ওয়্যারশার্ক উপস্থিত থাকলে তাদের এখনও দেখাতে হবে। 8 ম প্রচেষ্টাতে ক্লায়েন্ট টিসিপি / আইপি স্ট্যাকগুলি বিভিন্ন এসওয়াইএন প্যাকেটটিতে বিরক্তি প্রকাশ করেছিল এবং হঠাৎ এই কারণেই এটি স্বীকৃতি পেয়েছিল?

আপনি আমাদের ফ্রেম 539 অভ্যন্তরীণ মান প্রদান করতে পারেন? SYN / ACK কি সর্বদা এমন SYN প্যাকেটের জন্য আসে যা ডাব্লুএস সক্ষম করে না?

Comments

@ অ্যানিসিস: এখানে 539 টি ফ্রেমের জন্য কিছু স্ক্রিন শট দেওয়া হয়েছে (এটি দুটি অংশে করতে হয়েছিল): i.imgur.com/D84GC.png এবং i.imgur.com/4riq3.png

— কোডমোনকি

@ কোডোমনকি: আপনার 8 তম এসওয়াইএন প্যাকেটটি প্রথম সাত এসওয়াইএন প্যাকেটের চেয়ে আলাদা বলে মনে হচ্ছে। Tcp.options ক্ষেত্রের আকার 8 বাইটের (প্রথম সাতটি SYN প্যাকেটে সম্ভবত 20 বাইটের tcp.options থাকতে পারে) তখন কি সার্ভারটি ক্লায়েন্টের SYN এর সাথে SYN / ACK দিয়ে প্রতিক্রিয়া জানায়? সমস্যাটি অদৃশ্য হয়ে যায় কিনা তা দেখতে আপনি ক্লায়েন্টের পাশে টিসিপি উইন্ডো স্কেলিং অক্ষম করতে পারেন? সার্ভার সাইডে টিসিপি / আইপি স্ট্যাক বা কোথাও ভুল কনফিগার্ড ফায়ারওয়ালের সমস্যা মনে হচ্ছে ...

— হান্স সলো

@ অ্যানিসিস: হ্যাঁ, আপনি যেহেতু এটি দেখিয়েছেন এবং অন্য সমস্ত এসওয়াইএন প্যাকেটগুলি 24 বাইট রয়েছে আমি তা দেখছিলাম। আমি ক্লায়েন্টের উইন্ডো স্কেলিংটি অক্ষম করার চেষ্টা করব এবং সকালে ফলাফলগুলির সাথে ফিরে যাব।

— কোডমনকি

@ অ্যানিসিস: ক্লায়েন্টের উইন্ডোজ স্কেলিং বন্ধ করে দেওয়া সমস্যাটি থামিয়েছে। ধন্যবাদ! যাইহোক, এখন সার্ভারের দিক থেকে এটি কীভাবে ঠিক করতে হবে তা নির্ধারণ করা দরকার (যেহেতু আমরা আমাদের সমস্ত ক্লায়েন্টকে উইন্ডোজ স্কেলিং অক্ষম করতে পারি না) :) প্রশ্নে থাকা সার্ভারে নেট.ipv4.tcp_windows_scaling = 1

— কোডমোনকি

@ কোডমনকি: আমি একমত যে সমস্ত ক্লায়েন্টের উপর ডাব্লুএসকে অক্ষম করা কোনও সমাধান নয়, তবে আমরা কমপক্ষে ডাব্লুএস / প্যাকেট আকারের ইস্যুতে বিষয়টি সন্ধান করেছি। কারণটি অনুসন্ধান করার জন্য আমাদের ফায়ারওয়াল কীভাবে কনফিগার করা হয়েছে তা খতিয়ে দেখা উচিত। আপনি কি বিভিন্ন টিসিপি পোর্টের সাথে ডাব্লুএস এর সাথে টিসিপি সংযোগ স্থাপন করতে পারেন? বিভিন্ন সোর্স আইপি থেকে?

— হান্স সোলো

Answer 4

আমরা ঠিক ঠিক একই সমস্যায় পড়েছি (সিন্ন-অ্যাক না প্রেরণে সার্ভারে এটি পিন করতে সত্যিই বেশ খানিকটা সময় লেগেছিল)।

"সমাধানটি ছিল জনসাধারণের জন্য অ্যাক্সেসযোগ্য আমাদের সার্ভারগুলিতে টিসিপি উইন্ডোজ স্কেলিং এবং টিসিপি টাইমস্ট্যাম্পগুলি বন্ধ করে দেওয়া।"

Answer 5

আনিসিস যা বলেছে তা চালিয়ে নিতে, যখন ফায়ারওয়াল টিসিপি উইন্ডোজ স্কেলিং সমর্থন করে না তখন আমি এই জাতীয় সমস্যাগুলি দেখেছি। এই দুটি হোস্টের মধ্যে কী তৈরি / মডেল ফায়ারওয়াল?

Comments

ফায়ারওয়াল একটি ফেডোরা 13 বক্স iptables ব্যবহার করে। নেট.ipv4.tcp_windows_scaling 1 এ সেট করা আছে এই

— মেশিনেও

Answer 6

নিখোঁজ SYN / ACK ফায়ারওয়ালে আপনার SYNFLOOD সুরক্ষার খুব কম সীমাবদ্ধতার কারণে হতে পারে। এটি আপনার সার্ভার ব্যবহারকারীর সাথে কত সংযোগ তৈরি করে তার উপর নির্ভর করে। এসপিডি ব্যবহার করা সংযোগের সংখ্যা হ্রাস করবে এবং এমন পরিস্থিতিতে সাহায্য করতে পারে যেখানে net.ipv4.tcp_timestampsঅফ করা বন্ধ করে না।

Answer 7

এটি যখন শ্রেনী টিসিপি সকেটের ব্যাকলোগ পূর্ণ হয় তার আচরণ।

এনগনিক্স কনফিগারেশনে ব্যাকলগ আর্গুমেন্টটি সেট করার অনুমতি দেয়: http://wiki.nginx.org/HttpCoreModule#listen

শুনুন 80 ব্যাকলগ = সংখ্যা

1024 এর মতো ডিফল্টর চেয়ে বড় কিছুতে সংখ্যা সেট করার চেষ্টা করুন।

আমি কোনও গ্যারান্টি দিচ্ছি না যে একটি সম্পূর্ণ শ্রোতার সারি আসলে আপনার সমস্যা, তবে এটি যাচাই করা ভাল।

Comments

ভকভগক. আমি সর্বতভাবে চেষ্টা করব। আমরা ওএস পর্যায়ে ব্যাকলগ সেট করেছি, তবে স্পষ্টভাবে এনগিনেক্স কনফিগারেশনে নেই। আমি ফলাফল দিয়ে আপডেট করব।

— কোডমনকি

এটি আচরণটি একেবারেই বদলাতে পারেনি। অনুমান করুন, সমস্যা নেই? বা একমাত্র সমস্যা ...

— কোডমোনকি

টিসিপি সংযোগের জন্য অ্যাপ্লিকেশন স্তরের ব্যাকলগ প্যারামিটারের আকারের আকার নিয়ন্ত্রণ করে অর্থাৎ 3-মুখী হ্যান্ডশেক সমাপ্ত, অর্থাৎ সিন-অ্যাক পেয়েছে - সুতরাং এটি ওপি পরিস্থিতির সাথে মেলে না

— ygrek

Answer 8

আমি সবেমাত্র আবিষ্কার করেছি যে লিনাক্স টিসিপি ক্লায়েন্টরা 3 টি চেষ্টার পরে তাদের এসওয়াইএন প্যাকেট পরিবর্তন করে এবং উইন্ডো স্কেলিং বিকল্পটি সরিয়ে দেয়। আমি অনুমান করি কার্নেল বিকাশকারীরা বুঝতে পেরেছিলেন যে এটি ইন্টারনেটে সংযোগ ব্যর্থতার একটি সাধারণ কারণ

এটি ব্যাখ্যা করে যে এই ক্লায়েন্টরা কেন 11 সেকেন্ডের পরে সংযোগ স্থাপন করে (উইন্ডো-কম টিসিপি এসওয়াইএন 9 সেকেন্ড পরে আমার সংক্ষিপ্ত পরীক্ষায় ডিফল্ট সেটিংসের সাথে ঘটে)

Answer 9

আমারও একই সমস্যা ছিল, তবে আমার ক্ষেত্রে এটি ছিল টিসিপি চেকসাম যা ভুলভাবে গণনা করা হয়েছিল। ক্লায়েন্টটি একটি ভ্যাথের পিছনে ছিল এবং ইথটোল-কে ভ্যাথ0 ​​আরএক্স অফ টিএক্স অফ বন্ধ চালিয়েছিল trick