[
  {
    "courseSlug": "tcp-udp",
    "question": "TCP 3-way 핸드셰이크에서 세 마디가 오가는 올바른 순서는 무엇인가요?",
    "option1": "ACK → SYN → SYN+ACK",
    "option2": "SYN → ACK → SYN+ACK",
    "option3": "SYN → SYN+ACK → ACK",
    "option4": "SYN+ACK → SYN → ACK",
    "answerIndex": 2,
    "explanation": "섹션 2에서 배운 대로, 내 PC가 SYN으로 대화를 청하고 서버가 SYN+ACK으로 맞잡은 뒤 내 PC가 ACK으로 악수를 완성해야 연결이 수립됩니다."
  },
  {
    "courseSlug": "tcp-udp",
    "question": "코스에서 설명한 'UDP가 빠른 진짜 이유'로 가장 알맞은 것은 무엇인가요?",
    "option1": "연결 맺기·확인 답장·재전송 같은 일을 생략하기 때문에",
    "option2": "패킷을 TCP보다 훨씬 큰 크기로 쪼개서 보내기 때문에",
    "option3": "전용 회선을 미리 예약해서 다른 데이터가 못 끼어들기 때문에",
    "option4": "받는 쪽이 영수증(ACK)을 더 빠른 주기로 보내 주기 때문에",
    "answerIndex": 0,
    "explanation": "섹션 4의 핵심은 UDP의 속도가 '안 하는 일이 많아서' 나온다는 것입니다. 악수(3-way)도, ACK 확인도, 재전송도 하지 않는 대신 신뢰성을 포기한 대가로 속도를 얻습니다."
  },
  {
    "courseSlug": "tcp-udp",
    "question": "TCP로 상자 #1~#5를 보내다가 #3이 길에서 실종됐습니다. 이때 벌어지는 일로 옳은 것은 무엇인가요?",
    "option1": "받는 쪽이 #3 자리를 비워 둔 채 데이터를 미완성으로 조립한다",
    "option2": "보내는 쪽이 #1부터 #5까지 전부 처음부터 다시 보낸다",
    "option3": "받는 쪽이 연결을 끊고 3-way 핸드셰이크부터 다시 시작한다",
    "option4": "받는 쪽이 ACK로 알려 주면 보내는 쪽이 #3만 골라 재전송한다",
    "answerIndex": 3,
    "explanation": "섹션 3의 재전송·순서 보장 개념입니다. 받는 쪽이 '몇 번까지 잘 받았는지' 영수증(ACK)으로 알려 주므로, 실종된 #3만 다시 보내고 늦게 온 #3을 제자리에 끼워 넣어 원본과 100% 동일하게 복원합니다."
  },
  {
    "courseSlug": "tcp-udp",
    "question": "netstat 실습에서 원격 주소가 ':443'이고 상태가 ESTABLISHED인 줄이 뜻하는 것은 무엇인가요?",
    "option1": "내 PC가 SSH로 EC2 서버에 원격 접속해 있다는 뜻",
    "option2": "상대 서버의 HTTPS 방과 3-way 악수가 끝나 연결이 살아 있다는 뜻",
    "option3": "UDP 방송 수신이 진행 중이라 상태가 표시되고 있다는 뜻",
    "option4": "PostgreSQL 데이터베이스와 질의를 주고받는 중이라는 뜻",
    "answerIndex": 1,
    "explanation": "섹션 5~6에서 443번은 HTTPS의 방 번호이고, ESTABLISHED는 3-way 악수가 성공적으로 끝나 연결이 살아 있다는 표시라고 배웠습니다. 참고로 UDP는 연결 개념이 없어 이 명단에 상태가 뜨지 않습니다."
  },
  {
    "courseSlug": "tcp-udp",
    "question": "온라인 게임을 만들고 있습니다. 캐릭터의 실시간 위치는 UDP로 보내는데, '아이템 구매' 버튼까지 UDP로 보내자는 의견이 나왔다면 어떻게 판단해야 할까요?",
    "option1": "게임 데이터끼리는 같은 프로토콜을 써야 하므로 전부 UDP로 통일한다",
    "option2": "구매가 위치 정보보다 자주 발생하지 않으므로 UDP로 보내도 무방하다",
    "option3": "결제는 유실되면 안 되는 데이터이므로 느려도 TCP로 보내야 한다",
    "option4": "UDP로 보내되 헤더를 20바이트로 늘리면 유실을 막을 수 있다",
    "answerIndex": 2,
    "explanation": "섹션 7 토론(Q1)의 핵심 기준인 '이 데이터는 유실돼도 되는가?'를 적용한 문제입니다. 위치는 최신 정보가 곧 다시 오니 유실을 감수해도 되지만, 결제는 한 건이라도 유실되면 안 되므로 TCP를 써야 합니다."
  }
]
