ยอมรับได้หรือไม่ที่จะพึ่งพา ints แบบสุ่ม?

ฉันกำลังใช้โปรโตคอลเครือข่ายและฉันต้องการแพ็คเก็ตที่มีตัวระบุเฉพาะ จนถึงตอนนี้ฉันเพิ่งสร้างจำนวนเต็ม 32 บิตแบบสุ่มและสมมติว่ามันเป็นไปไม่ได้ทางดาราศาสตร์ที่จะเกิดการชนระหว่างอายุการใช้งานของโปรแกรม / การเชื่อมต่อ โดยทั่วไปถือว่าเป็นวิธีปฏิบัติที่ยอมรับได้ในรหัสการผลิตหรือเราควรกำหนดระบบที่ซับซ้อนเพื่อป้องกันการชนกันหรือไม่?

ระวังความขัดแย้งวันเกิด

สมมติว่าคุณกำลังสร้างลำดับของค่าสุ่ม (เหมือนกันเป็นอิสระ) จากชุดขนาด N (N = 2 ^ 32 ในกรณีของคุณ)

จากนั้นกฎของหัวแม่มือสำหรับวันเกิดความขัดแย้งระบุว่าเมื่อคุณสร้างค่าเกี่ยวกับ sqrt (N) อย่างน้อยมีโอกาส 50% ที่เกิดการชนนั่นคือนั่นมีค่าที่เหมือนกันอย่างน้อยสองค่าใน สร้างลำดับ

สำหรับ N = 2 ^ 32, sqrt (N) = 2 ^ 16 = 65536 ดังนั้นหลังจากที่คุณสร้างตัวบ่งชี้ประมาณ 65k ก็มีแนวโน้มว่าทั้งสองจะชนกันมากกว่า! หากคุณสร้างตัวระบุต่อวินาทีสิ่งนี้จะเกิดขึ้นในเวลาน้อยกว่าหนึ่งวัน จำเป็นต้องพูดโปรโตคอลเครือข่ายจำนวนมากทำงานเร็วกว่านั้น

มันเป็นที่ยอมรับกันอย่างกว้างขวางว่าต้องพึ่งพาตัวเลขสุ่มที่ไม่ซ้ำหากตัวเลขเหล่านั้นมีบิตเพียงพอ มีโปรโตคอลการเข้ารหัสลับที่การทำซ้ำหมายเลขสุ่มจะทำให้ความปลอดภัยทั้งหมดพัง และตราบใดที่ไม่มีช่องโหว่ร้ายแรงในตัวสร้างหมายเลขสุ่มที่ใช้นั่นก็ไม่ใช่ปัญหา

หนึ่งในอัลกอริทึมสำหรับการสร้าง UUID จะสร้าง ID ได้อย่างมีประสิทธิภาพประกอบด้วย 122 บิตสุ่มและคิดว่ามันจะไม่ซ้ำกัน และอัลกอริธึมอื่น ๆ อีกสองตัวนั้นขึ้นอยู่กับค่าแฮชที่ถูกตัดเป็น 122 บิตซึ่งมีความเป็นเอกลักษณ์ซึ่งมีความเสี่ยงในการชนกันโดยประมาณ

ดังนั้นจึงมีมาตรฐานที่ใช้ 122 บิตเพียงพอที่จะสร้างรหัสสุ่มที่ไม่ซ้ำกัน แต่ 32 บิตไม่เพียงพอ ด้วยรหัส 32 บิตจะใช้เวลาประมาณ2¹⁶ ID เท่านั้นก่อนที่ความเสี่ยงของการชนจะสูงถึง 50% เพราะด้วย ID 2¹⁶จะมีค่าใกล้เคียงกับ2³¹คู่ซึ่งแต่ละรายการอาจมีการชนกัน

แม้แต่ 122 บิตก็น้อยกว่าที่ฉันอยากจะแนะนำในการออกแบบใหม่ ๆ หากทำตามมาตรฐานบางอย่างมีความสำคัญต่อคุณให้ใช้ UUID มิฉะนั้นใช้สิ่งที่มีขนาดใหญ่กว่า 122 บิต

ฟังก์ชันแฮช SHA1 ที่มีเอาต์พุต 160 บิตจะไม่ถือว่ามีความปลอดภัยอีกต่อไปซึ่งส่วนหนึ่งเป็นเพราะ 160 บิตไม่เพียงพอที่จะรับประกันความเป็นเอกลักษณ์ของเอาต์พุต ฟังก์ชันแฮชที่ทันสมัยมีเอาต์พุตจาก 224 ถึง 512 บิต รหัสสุ่มที่สร้างขึ้นควรมีขนาดเท่ากันเพื่อให้แน่ใจว่ามีความปลอดภัยที่ไม่เหมือนใคร

ฉันจะเรียกการปฏิบัติที่ไม่ดีนี้ หมายเลขสุ่มสร้างไม่ได้สร้างตัวเลขเฉพาะพวกเขาเพียงแค่สร้างตัวเลขสุ่ม การกระจายแบบสุ่มมีแนวโน้มที่จะรวมรายการที่ซ้ำกัน คุณสามารถทำให้สถานการณ์นี้เป็นที่ยอมรับได้ยากโดยการเพิ่มองค์ประกอบของเวลา หากคุณได้รับเวลาปัจจุบันจากนาฬิการะบบหน่วยเป็นมิลลิวินาที บางสิ่งเช่นนี้

parseToInt(toString(System.currentTimeMillis()) + toString(Random.makeInt()))

จะไปไกล เห็นได้ชัดว่ารับประกันความเป็นเอกลักษณ์อย่างแท้จริงคุณต้องใช้ UUID / GUID แต่สิ่งเหล่านี้อาจมีราคาแพงในการสร้างสิ่งที่กล่าวมาข้างต้นน่าจะเพียงพอเนื่องจากความเป็นไปได้เพียงอย่างเดียวของการเหลื่อมกันคือถ้าการสร้างแบบสุ่มมีการทำซ้ำในมิลลิวินาทีเดียวกัน

ขึ้นอยู่กับความน่าจะเป็นของความล้มเหลวและผลที่ตามมาของความล้มเหลว

ฉันจำการอภิปรายระหว่างคนซอฟต์แวร์และฮาร์ดแวร์ที่คนฮาร์ดแวร์พิจารณาว่าอัลกอริทึมที่มีความน่าจะเป็นผลลัพธ์ที่ผิดเล็กน้อย (บางอย่างเช่นความล้มเหลว 1 ครั้งในรอบ 100 ปี) เป็นที่ยอมรับได้และคนซอฟต์แวร์คิดว่านี่เป็นคำสาปแช่ง มันกลับกลายเป็นว่าคนฮาร์ดแวร์คำนวณอัตราความล้มเหลวที่คาดไว้เป็นประจำและคุ้นเคยกับความคิดที่ว่าทุกอย่างจะให้คำตอบที่ผิดพลาดเป็นครั้งคราวเช่นเนื่องจากการรบกวนที่เกิดจากรังสีคอสมิก พวกเขาพบว่ามันแปลกที่ผู้คนคาดหวังความเชื่อถือได้ 100%

แน่นอนว่าคุณมีความน่าจะเป็นที่ต่ำของจำนวนเต็ม 32- บิตสุ่มสองตัวที่เรียงตามลำดับ แต่มันก็เป็นไปไม่ได้เลย การตัดสินใจทางวิศวกรรมที่เหมาะสมนั้นขึ้นอยู่กับว่าผลที่ตามมาของการชนคืออะไรการประมาณปริมาณของตัวเลขที่คุณกำลังสร้างอายุการใช้งานที่ต้องมีเอกลักษณ์และจะเกิดอะไรขึ้นหากผู้ใช้ที่ประสงค์ร้ายเริ่มพยายามทำให้เกิดการชน

เป็นที่ยอมรับได้เมื่อสมมติว่าตัวเลขสุ่มจะไม่ซ้ำกัน แต่คุณต้องระวัง

สมมติว่าตัวเลขสุ่มของคุณจะถูกกระจายอย่างเท่าเทียมกันน่าจะเป็นของการปะทะกันเป็นประมาณ (n ² /2) / k ที่ n คือจำนวนของตัวเลขสุ่มที่คุณสร้างและ k เป็นจำนวนของค่าที่เป็นไปได้เป็นจำนวนมาก "สุ่ม" สามารถใช้

คุณไม่ได้ใส่ตัวเลขในทางดาราศาสตร์ที่ไม่น่าจะเป็นไปได้ดังนั้นให้นำมันมาเป็น 1 ใน 2 ³⁰ (ประมาณเป็นพันล้าน) ให้บอกอีกว่าคุณสร้าง 2 ³⁰แพ็กเก็ต (ถ้าแต่ละแพ็กเก็ตแสดงข้อมูลประมาณหนึ่งกิโลไบต์ดังนั้นนี่หมายถึงเทราไบต์ของข้อมูลทั้งหมดซึ่งมีขนาดใหญ่ แต่ไม่มากจนเกินไป) เราพบว่าเราต้องการตัวเลขสุ่มที่มีค่าที่เป็นไปได้อย่างน้อย 2 ⁸⁹

ประการแรกตัวเลขสุ่มของคุณจะต้องใหญ่พอ จำนวนสุ่ม 32 บิตสามารถมีได้สูงสุด 2 ³²ค่าที่เป็นไป สำหรับเซิร์ฟเวอร์ไม่ว่างที่ไม่มีที่อยู่ใกล้สูงพอ

ประการที่สองตัวสร้างตัวเลขสุ่มของคุณต้องมีสถานะภายในที่มีขนาดใหญ่พอสมควร หากตัวสร้างตัวเลขสุ่มของคุณมีสถานะภายใน 32- บิตเท่านั้นไม่ว่ามูลค่าที่คุณสร้างนั้นจะใหญ่เพียงใดก็ตามคุณยังจะได้รับค่าที่เป็นไปได้มากที่สุด 2 ³²

ประการที่สามถ้าคุณต้องการตัวเลขสุ่มที่จะไม่ซ้ำกันในการเชื่อมต่อมากกว่าแค่ภายในการเชื่อมต่อเครื่องกำเนิดตัวเลขสุ่มของคุณจะต้องมีเมล็ดดี โดยเฉพาะอย่างยิ่งหากโปรแกรมของคุณเริ่มต้นใหม่บ่อยครั้ง

โดยทั่วไปเครื่องกำเนิดตัวเลขสุ่ม "ปกติ" ในภาษาการเขียนโปรแกรมไม่เหมาะสำหรับการใช้งานดังกล่าว เครื่องกำเนิดเลขสุ่มโดยห้องสมุดการเข้ารหัสโดยทั่วไปคือ

สร้างขึ้นในบางส่วนของคำตอบข้างต้นคือการสันนิษฐานว่าเครื่องกำเนิดเลขสุ่มนั้นแน่นอนว่า 'แบน' - ความน่าจะเป็นของตัวเลขสองตัวใด ๆ ที่ถูกสร้างขึ้นถัดไปจะเหมือนกัน

นั่นอาจไม่เป็นความจริงสำหรับตัวสร้างตัวเลขสุ่มส่วนใหญ่ ซึ่งส่วนใหญ่ใช้พหุนามลำดับสูงบางส่วนนำไปใช้ซ้ำกับเมล็ด

ที่กล่าวว่ามีหลายระบบออกมีที่ขึ้นอยู่กับรูปแบบนี้มักจะมี UUID ของ ตัวอย่างเช่นทุกวัตถุและทรัพย์สินใน Second Life มี UUID 128 บิตซึ่งสร้างแบบสุ่มและพวกเขาไม่ค่อยเกิดการชนกัน

ผู้คนจำนวนมากได้รับคำตอบที่มีคุณภาพสูง แต่ฉันต้องการเพิ่มจุดเล็ก ๆ น้อย ๆ : อันดับแรกจุดของ @nomadictype เกี่ยวกับวันเกิดความขัดแย้งนั้นยอดเยี่ยมมาก

อีกจุดหนึ่ง: การสุ่มนั้นไม่ตรงไปตรงมาในการสร้างและนิยามตามที่คนทั่วไปอาจคิด (อันที่จริงมีการทดสอบทางสถิติสำหรับการสุ่ม )

ด้วยสิ่งที่กล่าวมาสิ่งสำคัญคือต้องตระหนักถึงการเข้าใจผิดของนักการพนันซึ่งเป็นความเข้าใจผิดทางสถิติที่ผู้คนคิดว่าเหตุการณ์อิสระมีอิทธิพลต่อกัน โดยทั่วไปแล้วเหตุการณ์แบบสุ่มจะเป็นอิสระจากกันทางสถิติเช่นถ้าคุณสุ่มสร้าง "10" มันจะไม่เปลี่ยนความน่าจะเป็นในอนาคตของคุณในการสร้าง "10" มากขึ้นอย่างน้อย (อาจมีบางคนอาจเกิดข้อยกเว้นสำหรับกฎนั้น แต่ฉันคาดหวังว่าจะเป็นกรณีสำหรับเครื่องกำเนิดเลขสุ่มทั้งหมด)

ดังนั้นคำตอบของฉันคือถ้าคุณสามารถสันนิษฐานได้ว่าลำดับสุ่มที่มีความยาวเพียงพอนั้นไม่ซ้ำกันพวกเขาจะไม่เป็นตัวเลขสุ่มจริง ๆ เพราะนั่นจะเป็นรูปแบบทางสถิติที่ชัดเจน นอกจากนี้ก็จะหมายความว่าแต่ละหมายเลขใหม่ไม่ใช่เหตุการณ์ที่เป็นอิสระเพราะถ้าคุณสร้างเช่น 10 ที่จะหมายถึงความน่าจะเป็นในการสร้าง 10s ในอนาคตใด ๆ จะเป็น 0% (มันอาจจะไม่เกิดขึ้น) บวก นั่นหมายความว่าคุณจะเพิ่มอัตราต่อรองในการรับตัวเลขอื่นที่ไม่ใช่ 10 (เช่นยิ่งคุณสร้างจำนวนมากขึ้นความน่าจะเป็นของตัวเลขที่เหลืออยู่แต่ละตัวจะสูงขึ้น)

อีกสิ่งที่ควรพิจารณา: โอกาสที่จะชนะ Powerball จากการเล่นเกมเดียวคืออย่างที่ฉันเข้าใจแล้วว่าประมาณ 1 ใน 175 ล้าน อย่างไรก็ตามโอกาสของคนที่ชนะจะสูงกว่านั้นมาก คุณสนใจในอัตราต่อรองของใครบางคน "ชนะ" (เช่นการซ้ำซ้อน) มากกว่าในอัตราต่อรองของหมายเลขใด ๆ "ชนะ" / การซ้ำซ้อน

ไม่สำคัญว่าคุณใช้กี่บิตคุณไม่สามารถรับประกันได้ว่าตัวเลข "สุ่ม" สองหมายเลขจะแตกต่างกัน แต่ฉันขอแนะนำให้คุณใช้บางอย่างเช่นที่อยู่ IP หรือที่อยู่เครือข่ายอื่นของคอมพิวเตอร์และหมายเลขต่อเนื่องโดยควรเป็นหมายเลขลำดับ BIG ใหญ่ของ HONKIN - 128 บิต (ไม่ได้ลงนามอย่างชัดเจน) ดูเหมือนเป็นการเริ่มต้นที่ดี แต่ 256 จะดีกว่า

ไม่แน่นอน นอกจากว่าคุณใช้ตัวอย่างโดยไม่มีการเปลี่ยนใหม่มีโอกาสน้อยมากที่จะทำซ้ำ