지난시간까지
세션작업 완료를 하고,
라이브러리로 ServerCore를 따로 뺀 다음에
클라랑 컨텐츠(Server)에서 참조를 하도록 만들어 주었다.
1. 패킷 && TCP
그런데
우리가 지금은 문자열로만 통신을 하고 있었는데
나중에는 당연히 문자열로만 통신을 하지 않을 것이고
"패킷"이라는 개념으로 통신을 할 것이다.
클라랑 서버랑 합의된 규약을 서로 보내기 시작해야된다.
만약, 클라에서 "어느어느 좌표로 이동할 것이다!"라는 것을 서버에 보낼 것이다.
예를들어 "(3, 2)라는 좌표로 이동을 하고싶다!" 면
"이동 하고싶다!" 라는 패킷의 번호가 있을 것이고 (15번)
그러면 15 3 2 이렇게 서버에 보내면
서버에서는 15를 보고 아! 이동하고싶구나! 하고 3 2를 보고 아하 (3, 2)로 이동하고싶구나! 라는것을
까보면서 알게 될 것이다.
그래서 이제는
이런 문자열 단위로 보내는 것이 아니라
규약된 프로토콜대로 서로 데이터를 보내고 받고 분석을 해야된다는 얘기이다.
그래서 이동하는것을 15 다음에 정수 두개가와야된다고 프로토콜을 짜놓으면
서버에서는 15 3 2 라는 숫자를 다 받아야지만 분석을 해서 뭐 처리를 하든가 할 것이다.
하지만 어떤 이유로 15 3 까지만 왔다면 당연히 실행하면 안될 것이다.
(정보가 불충분 하니까)
왜 이런 얘기를 하냐하면은
우리는 지금 TCP 프로토콜을 이용해서 Send를 하고있었는데
내가 TCP를 사용해서 100Byte를 보낸다고 해서 받는입장에서 다 100Byte가 오는 것이 아니다!
TCP는 100Byte를 보낸다고 하더라도 너무 혼잡하거나 그러면 알아서 일부만 보내거나 그런 작업을 스스로 하게된다.
그래서 앞으로 TCP, UDP에대한 이해도가 어느정도는 있어야 앞으로 진행을 할 수 있다.
2. TCP 프로토콜
이런식으로 상품을 만들고 > 배송정책을 정하고 > 최종주소 기입 > 단지경로 & 택배 운송 이였다.
받는 사람 입장에서는
택배운송 & 단지경로 > 최종주소 > 배송정책 (맞다면) > 상품 수령 순이 될 것이다.
네트워크도 똑같은데
TCP를 사용할 것이냐? UDP를 사용할 것이냐는 "트랜스포트"단계에서 정하게 된다.
이미지는 이렇게 생각하면 될 것이다.
3. 연결 지향성
TCP = 연결형 서비스
UDP = 비연결형 서비스
4. 속도 신뢰성
5. 차이점
파란 부분이 우리가 게임을 만들때 핵심적인 부분이 된다.
우리가 TCP로 작업을 한다면 UDP보다 좋은점이 많다.
- 전송 순서가 보장
-> 순서가 보장이 안되면 막 뒤죽박죽 일텐데 이것을 지켜줌
- 분실시 책임지고 다시 재전송
-> 무조건 도착한다는 보장을 받을 수 있어서 도착한다는 보장하에 코딩구현 OK.
- 일부만 보냄
-> 흐름 / 혼잡제어를 해준다.(좋은점도 있고 안좋은 점도 있다 이부분은)
그래서 TCP쪽에서 상대방이 패킷을 받았다고 가정을 하면은,
(우리가 서버를 만든다고 가정을 하면은)
완전한 "패킷"이 온다는 것을 보장을 한다음에
그 녀석을 조립해서 사용해야된다는 얘기이다.
UDP는 끊어서 보내지 않기 때문에
무조건 "완전체"로 도착을 하게된다.
그래서
"부분적으로 갈 수 있냐 없냐?" == "바운더리 Boundary" 가 있냐? 없냐?
하는 부분도 TCP vs UDP에서 중요한 요소 라고 할 수 있다.
어쨋든 위에 설명한 것들은 굉장히 굉장히 중요하니까 생각을 해두어라.
코딩 && 면접 둘다 나온다.
6. 부연 설명
TCP가 속도가 느리다고 했는데
UDP에 비해서 느린거지 못써먹을 정도로 절망적으로 느린게 아니다.
그리고 우리를 대신해서 "프로토콜"딴에서 해주니까 이정도 속도는 감안을 하는게 좋다.
그리고 UDP를 사용하는 경우가 있는데
사실 패킷이 분실되어도 상관 없는 경우가 있다.
FPS게임인데
레이턴시가 가장중요하다.
어마어마하게 빠르게 응답을 해야지만 총게임을 하는 입장에서 굉장히 부드럽게 느낄텐데
"이동"을 하는 부분을 계속 중요하게 체크를 해야되는지는 의문이 있다.
어떤 패킷이 분실된다고 하더라도 그다음에 바로 전송되는 이동패킷이
그 좌표를 갱신을 하면은 사실은 별 상관없다.
그리고 UPD에서 "연결"이라는 개념이 없다는게 또 장점이기도 하다.
