مخفق المقبس لأن العميل لا يقرأ البيانات بسرعة كافية؟

Question

لديّ اتصال عميل/خادم عبر مقبس TCP ، مع كتابة الخادم إلى العميل بأسرع ما يمكن.

بالنظر إلى نشاط الشبكة الخاص بي ، يتلقى عميل الإنتاج بيانات بحوالي 2.5 ميجابايت/ثانية.

عميل جديد خفيف الوزن كتبته فقط لقراءة المعدل وقياسه ، يبلغ معدله حوالي 5.0 ميجابايت/ثانية (والذي ربما يكون حول سرعة الحد الأقصى الذي يمكن أن ينقله الخادم).

كنت أتساءل ما الذي يحكم المعدلات هنا ، لأن العميل لا يرسل أي بيانات إلى الخادم لإخبارها بأي حدود سعر.

Answer 1

في TCP هو العميل. إذا كانت نافذة TCP الخاصة بالخادم ممتلئة - فيجب أن تنتظر حتى يأتي المزيد من ACKs من العميل. يتم إخفاؤه عنك داخل مكدس TCP ، لكن TCP يقدم التسليم المضمون ، مما يعني أيضًا أن الخادم لا يمكنه إرسال البيانات بشكل أسرع من المعدل الذي يقوم العميل بمعالجته.

Answer 2

TCP لديه التحكم في التدفق ويحدث تلقائيًا. اقرأ عن ذلك في http://en.wikipedia.org/wiki/transmission_control_protocol#flow_control

عندما يملأ الأنبوب بسبب التحكم في التدفق ، لن يتم إكمال عمليات كتابة Server I/O حتى يتم إكمال التحكم في التدفق.

Answer 3

يقوم الخادم بكتابة البيانات بسرعة 5.0 ميغابايت/ثانية ، ولكن إذا كان عميلك هو عنق الزجاجة هنا ، فيجب على الخادم الانتظار قبل إرسال البيانات الموجودة في "المخزن المؤقت المرسل" بالكامل إلى العميل ، أو يتم إصدار مساحة كافية لوضع المزيد من البيانات.

كما قلت أن عميل الوزن الخفيف كان قادرًا على تلقيه عند 5.0 ميغابايت/ثانية ، فستكون عمليات ما بعد الاستقبال في عميلك يجب عليك التحقق منها. إذا كنت تتلقى البيانات ثم تقوم بمعالجتها قبل قراءة المزيد من البيانات ، فقد يكون هذا هو عنق الزجاجة.

من الأفضل تلقي البيانات بشكل غير متزامن ، وبمجرد اكتمال استلام المرء ، اطلب من مآخذ العميل البدء في تلقي البيانات مرة أخرى ، أثناء معالجة البيانات المستلمة في مؤشر ترابط مؤشر ترابط منفصل. وبهذه الطريقة ، يكون عميلك متاحًا دائمًا لتلقي البيانات غير المتوفرة ، ويمكن أن يرسلها الخادم بأقصى سرعة.