السلام عليكم ورحمه الله وبركاته ...
اود السؤال عن ال Socket Flood هل يمكن sends اكثر من connection الي ال Host في نفس اللحظة .. وايهما افضل في TCP ام UDP ..
شكرا :)
السلام عليكم ورحمه الله وبركاته ...
اود السؤال عن ال Socket Flood هل يمكن sends اكثر من connection الي ال Host في نفس اللحظة .. وايهما افضل في TCP ام UDP ..
شكرا :)


http://objectmix.com/java/71911-socket-flood-control-xml-packets-when-all-received.html
ياريت يا أخي لو لقيت نتيجه تقلنا, عشان أنا مهتم اليومين دول بموضوع الشبكات ده,,,
اقتباساود السؤال عن ال Socket Flood هل يمكن sends اكثر من connection الي ال Host في نفس اللحظة .. وايهما افضل في TCP ام UDP ..
أخي الـ UDP عبارة عن Connectionless Protocol, بمعنى أنك ترسل Datagram إلى الطرف الآخر دون عملية اتصال أساساً. تخيل أنك تريد إرسال SMS إلى جوال شخص آخر, هل تقوم بعملية اتصال؟
بالطبع لا, هل تعرف هل وصلت الرسالة أم لا؟ بالطبع لا!
الآن كيف يمكن أن تغرق الـ Socket الذي تريد مهاجمته في هذه الحالة؟
تحتاج إلى Server أقوى من السيرفر الذي تقوم بمهاجمته, و ذلك لإغراق السيرفر المقابل. أقوى هنا تعني أنك تستطيع إرسال Datagrams أسرع مما يستطيع السيرفر الذي تريد مهاجمته من معالجتها.
هذا الأمر, لا أعتقد أنه ممكن باستخدام حاسوب شخصي واحد, مقابل Server أقوى بعدة مرات مخصص للعمل على الانترنت.
الحالة الثانية هي كون الـ Protocol المستخدم هو TCP.
المشكلة في TCP, هي عملية الـ Three Way Hand Shaking. و فهم هذه العملية سيعطيك فكرة عن الـ Socket Flooding.
عندما تقوم بفتح إتصال, فإنك ترسل SYN, في هذه الحالة, فإن السيرفر سيقوم بحجز الـ Buffers اللازمة لعملية الـ Flow Control, و موارد أخرى و خلافه.
و سيرد بـ SYN+ACK على المتصل, ثم ينتظر الـ Server المتصل لكي يرسل الـ ACK النهائية لكي يكون الإتصال مفتوحاً من الطرفين.
حتى الآن كل شيء سليم.
الذي يمكن أن يحصل, هو تقوم بوضع IP وهمي في الـ IP Packet التي تحتضن طلب الإتصال, بحيث عندما يقوم السيرفر بحجز الموارد و الرد بـ SYN+ACK فإن الرد يضيع على شبكة الانترنت, لأن الـ IP الذي تم الرد عليه,
عبارة عن IP وهمي, و لم يقم بفتح الإتصال أصلاً. باختصار. أنت تقوم بعمل إتصال, و لكن تقوم بوضع IP وهمي في الـ IP Packet. و هكذا ترسل العديد منها, بحيث يوم السيرفر بعملية حجز موارد كثيرة مقابل طلبات صغيرة نسبياً من قبلك.
هناك حلول كثيرة للمشكلة, كما في SCTP Protocol حيث يتم استعمال Cookie للتأكد من وجود متصل حقيقي. هناك أيضاً, عملية تحديد عدد عمليات الإتصال المسموحة بشكل عام خلال فترة زمنية معينة.
هذا مالدي, عدا عن ذلك فتحتاج إلى شخص يفهم في الشبكات ليخبرك بالتفاصيل.
تحياتي...
تم تعديل هذه المشاركة بواسطة Khaled.Alshaya في 10 أبريل 2010 في 03:14
إذا فهمت سؤالك بشكل صحيح، فهي أنك تريد أرسال رسالة لعدة مستقبلين (broadcasting) عن طريق زبون واحد Client
هذا الموضوع بطبيقه على الـ UDP أسهل من TCP لكن عليك أن تتأكد من عمل Acknowledgment mechanism خاصة بالمستقبل.
الطريقة كالتالي:
المرسل
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package playground;
import java.io.IOException;
import java.net.DatagramPacket;
import java.net.InetAddress;
import java.net.MulticastSocket;
import java.util.logging.Level;
import java.util.logging.Logger;
/**
*
* @author Yasser
*/
public class Sender {
public static void main(String[] args){
try {
MulticastSocket s = new MulticastSocket(1024);
s.setBroadcast(true);
String message = "hello";
byte[] buffer = message.getBytes();
DatagramPacket data = new DatagramPacket(buffer, 0, buffer.length,
InetAddress.getByName("225.0.0.1"), s.getLocalPort());
s.send(data);
System.out.println("message sent: " + message);
} catch (IOException ex) {
Logger.getLogger(Sender.class.getName()).log(Level.SEVERE, null, ex);
}
}
}المستقبل
/*
* To change this template, choose Tools | Templates
* and open the template in the editor.
*/
package playground;
import java.io.IOException;
import java.net.DatagramPacket;
import java.net.InetAddress;
import java.net.MulticastSocket;
import java.util.logging.Level;
import java.util.logging.Logger;
/**
*
* @author Yasser
*/
public class Receiver {
public static void main(String[] args){
try {
MulticastSocket socket = new MulticastSocket(1024);
socket.joinGroup(InetAddress.getByName("225.0.0.1"));
byte[] buffer = new byte[1024];
System.out.println("Socket created, waiting for message");
DatagramPacket data = new DatagramPacket(buffer, buffer.length);
socket.receive(data);
System.out.println("received message: " + new String(buffer));
} catch (IOException ex) {
Logger.getLogger(Receiver.class.getName()).log(Level.SEVERE, null, ex);
}
}
}لا أحب هذه المواضيع على الأغلب
لا يأتي منها سوى وجع الرأس
الفائدة الوحيدة التي أراها لها هي الاحتياط
اقتباسعندما تقوم بفتح إتصال, فإنك ترسل SYN, في هذه الحالة, فإن السيرفر سيقوم بحجز الـ Buffers اللازمة لعملية الـ Flow Control, و موارد أخرى و خلافه.
و سيرد بـ SYN+ACK على المتصل, ثم ينتظر الـ Server المتصل لكي يرسل الـ ACK النهائية لكي يكون الإتصال مفتوحاً من الطرفين.
أعتقد أن هذه مشكلة كبيرة في TCP ولا أعتقد أنها مازالت موجودة حتى اليوم
وإلا لكنت وجدت الآلاف من المواقع مغلقة ببساطة
تحياتي
تم تعديل هذه المشاركة بواسطة علاء الصالحي في 10 أبريل 2010 في 06:37
بالعكس أخ علاء,
مواضيع الـ Security من أجمل المواضيع, و صدقني ليس القصد عملية استغلال الثغرات نفسها.
أما عن الـ SYN Flood فهو موجود منذ وجد TCP, و سيبقى حتى ينتهي TCP. المشكلة في البروتوكول نفسه, و ليست في جانب آخر.
لهذا تم تطوير SCTP, و لكن عجلة التكنلوجيا تتحرك أبطأ مما نتصور خصوصاً عن الحديث عن الشبكات. هذا بروتوكول مضى عليه ما يقارب الثلاثة عقود, و مازال الجميع يعمل به للتوافقية لا أكثر.
و إلا بروتوكول SCTP يوفر حلول لمشاكل TCP.
لذلك أي حل يستخدم TCP في الأساس هو ليس حلاً و إنما عملية "ترقيع" للمشكلة.
تحياتي...
Technical Lead Developer
اللهم قنى شر الجهل و الجهلاء
( اقْتَرَبَ لِلنَّاسِ حِسَابُهُمْ وَهُمْ فِي غَفْلَةٍ مَّعْرِضُونَ ) {الأنبياء:1}
اخ خالد لي رجعه في عده نقاط لم افهمها . هل يمكن استخدام Threading هنا مثلا :
public void run()
{
for(int i = 0; i < connections; i++)
{
if(on = true) {
try
{
socket = new Socket(host, port);
System.out.println("Sent connection " + i + " to " + host + ": " + port);
} catch(Exception e) {
e.printStackTrace();
}
}
}
}
