কোনও নির্দিষ্ট সাইট থেকে কোনও পৃষ্ঠা আনার সময় বড় বিলম্ব

Question

আমার নিম্নলিখিত সমস্যা রয়েছে: যখন আমি হ্যাকেজ থেকে কোনও পৃষ্ঠা পুনরুদ্ধার করি তখন আমি একটি বড় বিলম্ব (প্রায় 30 সেকেন্ড) পাই। আরও অনুরোধগুলি দ্রুত, তবে আমি কয়েক মিনিটের মধ্যে যদি এটির সাথে সংযোগ না করি তবে সমস্যা ফিরে আসবে।

এই সমস্যাটি সম্পর্কে আকর্ষণীয়টি হ'ল:

• এটি এই নির্দিষ্ট সাইটের সাথে সুনির্দিষ্ট (হ্যাকেজ) - আমি অন্য কোনও সাইটের সাথে একই ধরণের সমস্যা পাই না (এবং আমি বেশ কয়েকটি পরিদর্শন করি);
• এটি আমার আইএসপির সাথে সুনির্দিষ্ট বলে মনে হচ্ছে - যখন আমি অন্য জায়গা থেকে সংযোগ করি তখন এ জাতীয় কোনও সমস্যা হয় না;

• এটি ডিএনএস বা সংযোগ সমস্যার সাথে সম্পর্কিত নয় - আসলে, টিসিপি সংযোগটি দ্রুত প্রতিষ্ঠিত হয়েছে; এটি নীচের নমুনা প্যাকেট ক্যাপচার থেকে দেখা যায় যে এটি খুব দীর্ঘ সময় লাগে এইচটিটিপি প্রতিক্রিয়া:

    1 0.000000000 192.168.1.101 -> 66.193.37.204 TCP 66 41518 > http [SYN] Seq=0 Win=13600 Len=0 MSS=1360 SACK_PERM=1 WS=16
    2 0.205708000 66.193.37.204 -> 192.168.1.101 TCP 66 http > 41518 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1440 SACK_PERM=1 WS=128
    3 0.205759000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=1 Ack=1 Win=13600 Len=0
    4 0.205846000 192.168.1.101 -> 66.193.37.204 HTTP 158 GET /packages/hackage.html HTTP/1.1 
    5 0.406461000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [ACK] Seq=1 Ack=105 Win=5888 Len=0
    6 28.433860000 66.193.37.204 -> 192.168.1.101 TCP 1494 [TCP segment of a reassembled PDU]
    7 28.433904000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=1441 Win=16480 Len=0
    8 28.434211000 66.193.37.204 -> 192.168.1.101 HTTP 1404 HTTP/1.1 200 OK  (text/html)
    9 28.434228000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=105 Ack=2791 Win=19360 Len=0
   10 28.434437000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [FIN, ACK] Seq=105 Ack=2791 Win=19360 Len=0
   11 28.635146000 66.193.37.204 -> 192.168.1.101 TCP 54 http > 41518 [FIN, ACK] Seq=2791 Ack=106 Win=5888 Len=0
   12 28.635191000 192.168.1.101 -> 66.193.37.204 TCP 54 41518 > http [ACK] Seq=106 Ack=2792 Win=19360 Len=0
  

  ( প্যাকেট-এনজি ফর্ম্যাটে প্যাকেট ক্যাপচার )। এই ক্যাপচারটি দেখায় যে একটি সরল সময়ে কী ঘটে curl http://hackage.haskell.org/packages/hackage.html।

আমি কোনও রাউটারের পিছনে আছি তা নিয়েও কিছু আসে যায় না - আমি সরাসরি সংযোগ করি যখন এটি একই হয়। সংযোগের ধরনটি পিপিপিওইই।

লিনাক্স এবং উইন্ডোজ চালিত 3 টি কম্পিউটারে আমি সমস্যাটি পুনরুত্পাদন করেছি।

কীভাবে এ জাতীয় সমস্যা নির্ণয় করা যায়?

Comments

হাই, আমি মনে করি আপনাকে আইপি স্তরের কথোপকথনের পরিবর্তে এইচটিটিপি স্তর সংলাপটি দেখতে সক্ষম বিকাশকারী সরঞ্জাম সহ একটি ব্রাউজার ব্যবহার করা উচিত। আমাদের বিলম্বের কারণ ঘটছে তা দেখতে হবে এবং আপনি কেবল পৃষ্ঠার জন্য এইচটিটিপি ইন্টারেক্টিভের মোট সেটটি দেখে এটি করতে পারেন। পরিবর্তে, আপনি GMetrix ব্যবহার করতে পারে ।

— জুলিয়ান নাইট

সাইটে জিমেট্রিক্স চালানো বেশ কয়েকটি উল্লেখযোগ্য প্রত্যাশা নিয়ে আপনাকে বেশ ভাল ফলাফল দিয়েছে যা আপনাকে সঠিক দিক নির্দেশ করতে পারে।

— জুলিয়ান নাইট

@ জুলিয়ানকাটায়: প্রশ্নের সম্পূর্ণ ক্যাপচার ফাইলের একটি লিঙ্ক আছে - এতে সমস্ত তথ্য রয়েছে

— রোমান চ্যাপলিয়াকা

আপনার লিঙ্কটি একটি পিসিএপি, আমি অনেক উচ্চ স্তরের কিছু উল্লেখ করছি। ব্রাউজার-ভিত্তিক বিকাশকারী বিশ্লেষণ বা GMetrix বা উভয়ই ব্যবহার করে ফিরে রিপোর্ট করুন।

— জুলিয়ান নাইট

@ জুলিয়ানকাটায়: আমাকে পুনরাবৃত্তি করুন - সিএসএস এখানে অপ্রাসঙ্গিক, এবং আমরা একক এইচটিটিপি অনুরোধের জন্য 30 সেকেন্ডের বিলম্বের কথা বলছি ।

— রোমান চ্যাপলিয়াকা

Answer 1

"30 সেকেন্ড" এবং "দুই মিনিটের পরে" আমার কাছে ডিএনএস ইস্যুতে একটি মৃত রিঞ্জার।

যদি আমরা ধরে নিই যে আপনি যে পৃষ্ঠায় সংযোগ করছেন সেটি সংযোগকারী আইপি-তে কোনও ডিএনএস কোয়েরির মতো কিছু করে, এবং সেই কোয়েরিটি কোনও কারণে ব্যর্থ হয়, আপনি দেখতে পাবেন:

• TCP সংযোগ প্রায় তাত্ক্ষণিক যেহেতু সার্ভার DNS চেক করছে না
• স্ক্রিপ্টটি একটি ডিএনএস কোয়েরি চালায় এবং আটকে যায় ।
• 30 সেকেন্ড পরে ডিফল্ট সময়সীমা শেষ হয়ে যায় এবং স্ক্রিপ্টটি চলে যায় (আপনি এখন "অজানা")
• পরবর্তী প্রশ্নগুলিতে, নেতিবাচক ডিএনএস হিটটি এখনও ক্যাশেড রয়েছে এবং প্রথম ধাপটি কোনও সময় ছাড়িয়ে যায়
• নেতিবাচক সময়সীমা শেষ হওয়ার পরে (আরএফসি 2308), এবং এটি 2 এবং 5 মিনিটের মধ্যে যে কোনও কিছু, পরবর্তী সংযোগে একটি নতুন ক্যোয়ারী জারি করা হয় এবং গল্পটি পুনরাবৃত্তি করে।

... এবং এগুলি হ'ল লক্ষণগুলি যা আপনি বর্ণনা করছেন।

আপনি আইএসপি 1 থেকে প্রাপ্ত আইপিতে অন্য আইএসপি (বলুন, আইএসপি 2) থেকে ডিএনএস কোয়েরি চালানোর চেষ্টা করতে পারেন। এটি 100% প্রমাণ নয়, তবে আমি উচ্চ সম্ভাবনাটি আশা করি যে ক্যোয়ারীটি শেষ হতে 30 সেকেন্ড সময় লাগবে। এর অর্থ হ'ল আইএসপি 1 ডিএনএস সার্ভারের বাইরে থেকে প্রশ্নের উত্তর দিতে সমস্যা হচ্ছে ।

আর একটি সম্ভাব্য কারণ হ'ল আইপিপি 1 এর ডিএনএস হ্যাকেজ দ্বারা ফায়ারওয়াল করা (সম্ভবত ভুলভাবে) কারণে করা যেতে পারে ( আমার পোশাকে, কারণটি হবে "ট্রিগার-হ্যাপি নেটডমিন" এবং আমি নামগুলির নাম দিতে পারি)। সেক্ষেত্রে আপনার নির্ণয় করা অনেক বেশি কঠিন সময় হবে, আইএসপি 2 এর মাধ্যমে যে কোনও পরীক্ষার জন্য অস্বাভাবিক কিছুই ফিরে আসবে না; আপনি হ্যাকেজ এ এড়াতে হবে।

Comments

এটা দেখতে খুব প্রশংসাসূচক! আমাকে এটি যাচাই করুন।

— রোমান চ্যাপলিয়াকা

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

— harrymc

@harrymc: এটি আসলে খুব সহজ। বিপরীত ডিএনএসের জন্য দায়বদ্ধ আমার আইএসপির ডিএনএস সার্ভারগুলি নিচে রয়েছে। সুতরাং, সময়টি বিপরীত সমাধানের চেষ্টা করুন। এই চেষ্টা করুন: dig +trace -x 80.90.233.38। আমি 95% নিশ্চিত যে এটিই কারণ, কেবল নিশ্চিতকরণের জন্য অপেক্ষা করছি যে হ্যাকেজ সত্যই বিপরীত ডিএনএস লুকআপগুলি সম্পাদন করে।

— রোমান চ্যাপ্লিয়াকা

Answer 2

"এমটিইউ" দিয়ে সমস্যা মনে হচ্ছে সমস্যার মতো। আপনি যদি "উইন্ডোজ সেটিং এমটিটিউ" গুগল করেন তবে আপনাকে বেশ কয়েকটি প্রতিক্রিয়া উপস্থিত করা উচিত যা আপনাকে এই তত্ত্বটি কীভাবে পরীক্ষা করতে হবে তা দেখাবে এবং যথাযথভাবে আপনার এমটিইউ হ্রাস করবে। (আপনি যদি একটি লিনাক্স রাউটার ব্যবহার করে থাকেন তবে আমি আপনার জন্য এটি ডায়নামিকভাবে করার জন্য একটি আইপিটবেল কমান্ড তৈরি করতে পারতাম, তবে আমি উইন্ডোজ "করি" না))

Comments

ওয়্যারশার্ক গাইড অনুসারে, "রিসেম্বলড পিডিইউর টিসিপি বিভাগ" আসলে আইপি ফ্রেগমেন্টেশনের সাথে সামঞ্জস্য নয় বরং এটি কেবল ইঙ্গিত করে যে প্রতিক্রিয়াটিতে বৈধভাবে একাধিক প্যাকেট রয়েছে যা আপনি কোনও ওয়েব পৃষ্ঠার কাছ থেকে আশা করবেন।

— জুলিয়ান নাইট 21

এটি এমটিইউ বলে মনে হচ্ছে না। আমি ইথারনেটের মাধ্যমে সরাসরি সংযোগ করে এবং এমটিটিউ 1000 এ সেট করে এটি পরীক্ষা করেছি The সমস্যাটি এখনও অব্যাহত।

— রোমান চ্যাপলিয়াকা

Answer 3

আমি আপনার প্যাকেটগুলি ক্যাপচারের পুনরাবৃত্তি করেছি, যা আমার শেষ দিকে এইভাবে দেখায়:

প্যাকেটটি পুনরায় সংযুক্ত করার সময় কার্যকরভাবে একটি ছোটখাটো অন্বেষণযোগ্য বিরতি রয়েছে, তবে যতক্ষণ আপনার নিজের নয়। আমি সমস্ত আইপি-ঠিকানা এবং এইচটিএমএলও যাচাই করেছি এবং সবকিছু সঠিক এবং অত্যন্ত সহজ এবং নিরীহ দেখাচ্ছে।

সংক্ষেপে, যতক্ষণ ইন্টারনেট সম্পর্কিত, এই বিলম্বের কোনও কারণ নেই। উপসংহারটি হ'ল আপনার আইএসপি নিয়ে একটি সমস্যা আছে।

সম্ভাবনাগুলি সঙ্কুচিত করতে আপনি যা করতে পারেন তা হ'ল:

1. অন্য haskell.org প্যাকেজের সাথে সংযোগ স্থাপনের চেষ্টা করুন এবং দেখুন কোনও অনুরূপ বিলম্ব আছে কিনা
2. বিভিন্ন নেটওয়ার্ক অ্যাডাপ্টার ব্যবহার করে বেশ কয়েকটি কম্পিউটারের সাহায্যে আপনার জায়গা থেকে অন্য রাউটার ব্যবহার করার চেষ্টা করুন
3. আপনার অঞ্চলে এমন কাউকে রাখার চেষ্টা করুন যা একই আইএসপি ব্যবহার করে সংযোগটি পুনরাবৃত্তি করে
4. আপনার অঞ্চলে এমন কাউকে থাকার চেষ্টা করুন যা অন্য আইএসপি ব্যবহার করে সংযোগটি পুনরাবৃত্তি করে
5. এই তথ্যের সাথে, যদি এখনও আপনার এই বিলম্বের কোনও ব্যাখ্যা না থাকে তবে কী চলছে তা জানতে আপনার আইএসপি সাপোর্টের সাথে যোগাযোগ করুন।

[Edit]

আমি লক্ষ্য করেছি haskell.org একটি পাঠায় ETag যাতে ব্যাখ্যা দিয়েছে কেন প্রথম এক্সেস ধীর কিন্তু পরবর্তী বেশী দ্রুত,: যেহেতু জন্য যতদিন ETag বৈধ হিসাবে, পৃষ্ঠা আসলে আপনার ব্রাউজারের ক্যাশে থেকে আসে।

এখানে অদ্ভুত অংশটি হ'ল কেন ইটিগ অনুরোধ প্রেরণ করার সময় আইএসপি ধীর হয় না। একটি ব্যাখ্যা হতে পারে যে সীমিত সময়ের জন্য তারা haskell.org এ যাওয়ার পরিবর্তে তাদের নিজস্ব ক্যাশে থেকে অনুরোধটি সন্তুষ্ট করে।

Comments

1. এটি সমস্ত হ্যাকেজ পৃষ্ঠাগুলির জন্য একই। ২. যেমনটি আমি বলেছি, আমি এটি বেশ কয়েকটি কম্পিউটারে এবং বেশ কয়েকটি রাউটার (এবং একটি ছাড়াই) দিয়ে চেষ্টা করেছি। ৪. আমি যদি আমার অঞ্চলে অন্য আইএসপি ব্যবহার করি তবে সমস্যাটি নেই।

— রোমান চ্যাপলিয়াকা

এখন, আইএসপি সমস্যাটি সত্যই একমাত্র সমাধানযোগ্য সমাধানের মতো দেখায়, তবে এটি কী ধরণের সমস্যা হতে পারে? তারা সম্ভবত হ্যাকের অস্তিত্ব সম্পর্কে সন্দেহও করে না, তাই এটি উদ্দেশ্যমূলক হতে পারে না। যদি আমি তাদের বলি, "আরে, এই এক সাইটটি আমার পক্ষে কাজ করে না (তবে অন্যরা সবাই করেন)", তারা শুনবে না।

— রোমান চ্যাপলিয়াকা

আমি কেন প্রথম প্রথম অ্যাক্সেসটি ধীর করে দেয় তার উপরে একটি ব্যাখ্যা জুড়েছি। আইএসপির সাথে কথা বলার আগে পয়েন্ট 3 এর এখনও একটি উত্তর দরকার। তাদের সমস্যাটি সুরক্ষিত সফ্টওয়্যার সম্পর্কিত হতে পারে যা তারা নিয়োগ করে, কারণের কারণে haskell.org এর বৈধতা পরীক্ষা করতে খুব ধীর হয়ে পড়ে।

— harrymc

ইটাগ অপ্রাসঙ্গিক, যেহেতু আমি পরীক্ষার জন্য কার্ল ব্যবহার করি। যাইহোক, বিপরীত ডিএনএস সম্পর্কে উত্তর সম্ভবত সঠিক।

— রোমান চ্যাপলিয়াকা

Answer 4

এটি একটি সার্ভার সমস্যা মত শোনাচ্ছে। এটা আমার জন্য দ্রুত বোঝা। সার্ভার আপনাকে অপছন্দ করে কিনা তা পরীক্ষা করার জন্য এটি টিওআর বা হাইডমাইআস.কম এর মতো প্রক্সি থেকে অ্যাক্সেস করার চেষ্টা করুন। যদি এটি দ্রুত হয় তবে haskell.org এবং আপনার বাড়ির মধ্যে সমস্যা আছে।

আপনি চালাতে পারেন এমন আরও একটি পরীক্ষা হ'ল এইচটিএমএল ফাইল, সিএসএস ফাইল, বা এক্সএমএল ফাইলের মতো সেই দৃষ্টির কোনও সংস্থান খুঁজে পাওয়া এবং সেই লিঙ্কটি কোনও এইচটিএমএল বৈধকরণকারীর কাছে প্রেরণ করা ইত্যাদি If যদি তৃতীয় পক্ষের পরিষেবাগুলি পেতে খুব বেশি সময় লাগে, তবে এটি সার্ভারের সাথে সমস্যা।

অন্য পরীক্ষা: আপনার ডিএনএস ক্যাশে সাফ করুন। এটি haskell.org এর আইপি অ্যাড্রেসটি দেখতে অনেক দিন সময় নিয়েছে। ipconfig /flushdns। ping hackage.haskell.orgকমান্ড লাইন থেকেও দেখতে চেষ্টা করুন যে আইপি ঠিকানাটি সন্ধান করতে কতক্ষণ সময় লাগে।

আরেকটি পরীক্ষা: কুকিজ না পাঠাতে Chrome (এবং অন্যদের) সাথে একটি ব্যক্তিগত ব্রাউজিং সেশন খুলুন।

অন্য পরীক্ষা: ক্রোম বা অপেরাতে F12 খুলুন, নেটওয়ার্ক ট্যাবে যান এবং তারপরে প্রতিটি সংস্থার সময় দেখতে সাইটে যান।

Comments

প্রক্সি ব্যবহার করার সময় সমস্যাটি চলে যায়। আপনার অন্যান্য পরামর্শ ইতিমধ্যে প্রশ্নে সম্বোধন করা হয়েছে।

— রোমান চ্যাপলিয়াকা

সার্ভারটি আপনাকে পছন্দ করে না। এটি যে কারণেই হোক না কেন এটি আপনার আইপি থ্রটল করছে। এখানে আপনার কিছু করার মত নেই।

— ক্লো