레이블이 Network인 게시물을 표시합니다. 모든 게시물 표시
레이블이 Network인 게시물을 표시합니다. 모든 게시물 표시

10월 28, 2016

HTTP


HTTP (HyperText Transfer Protocol)

WWW 상에서 정보를 주고 받을 수 있는 프로토콜로 HTML 문서 및 다른 종류의 데이터를 주고 받는데 사용. TCP, UDP 방식을 사용하며 80번 포트를 이용함. 버전 0.9, 버전 1.0 및 버전 1.1이 존재하는데 현재 대부분 버전 1.0 이나 버전 1.1을 사용함. HTTP/2를 개발 중.

HTTP는 클라이언트와 서버 사이의 요청/응답(request/response) 프로토콜로 요청 메시지, 응답 메시지가 각각 구분되어 있으며 이에 따라 공통으로 사용되는 헤더와 request 헤더, response 헤더가 존재함. 먼저 클라이언트가 서버에 연결을 요청하면 Connect, Request, Response, Close 과정을 거쳐 통신을 수행함. 버전 0.9 의 경우 같은 페이지 내에서도 요소마다 Connect와 Close 과정을 거쳐서 효율이 매우 떨어졌지만, 버전 1.0 부터 한번의 Connect 후에 Request와 Response를 반복할 수 있게 됨.


HTTP Request

HTTP Request |devwoodo's blog

HTTP Response

HTTP Response |devwoodo's blog

reference

작성자: 시간: 댓글 없음:
라벨: , , , ,

HTTP Response


내용

HTTP Response 는 HTTP Request 에 대한 응답 패킷. 서버에서 쓰이고 있는 프로토콜 버전, Request에 대한 실행 결과 코드(HTTP Status code), 간략한 실행 결과 설명문(OK 등)이 담겨 있으며, 전달할 데이터 형식, 데이터 길이 등 추가 정보가 MIME 형식으로 표현되어 있음. 그리고 헤더 정보 뒤에는 실제 데이터가 담겨 있음.


HTTP Status code (HTTP Response의 실행 결과 코드)

1XX (조건부 응답)

요청을 받았으며 작업을 계속함을 의미.

2XX (성공)

클라이언트의 요청을 수신하여 이해하고 승낙했으며, 성공적으로 처리했음을 의미

  • 200(Ok)
  • 201(Create)
  • 202(Accepted)
  • 203(Non-Authoritative Information)
  • 204(No Content)
  • 205(Reset Content)
  • ...

3XX (리디렉션 완료)

요청을 마치기 위해 클라이언트가 추가 동작을 취해야 하는 경우


4XX (요청 오류)

클라이언트에 오류가 있는 경우

  • 400(Bad Request) : 서버가 요청의 구문을 인식하지 못함
  • 401(Unauthorized) : 이 요청은 인증이 필요함
  • 403(Forbidden) : 서버가 요청을 거부함
  • 404(Not Found) : 서버가 요청 받은 페이지를 찾을 수 없음
  • 405(Method Not Allowed) : 요청에 지정된 방법을 사용할 수 없음
  • 406(Not Acceptable)
  • 408(Request Timeout) : 서버의 요청대기가 시간을 초과함
  • ...

5XX (서버 오류)

유효한 요청을 서버가 명백히 수행하지 못했음을 의미

  • 500(Internal Server Error) : 서버에 오류 발생해 요청을 수행할 수 없음
  • 501(Not Implemeted) : 서버에 요청을 수행할 수 있는 기능이 없음. ex) 서버가 요청 메소드를 인식하지 못할 때
  • 502(Bad Gateway) : 잘못된 응답을 받음
  • 503(Service Unavailable) : 서버가 오버로드 되거나 유지 보수를 위해 다운됨. 대게 일시적인 상태
  • 504(Gateway Timeout) : 제 때 응답을 받지 못함
  • ...

reference


작성자: 시간: 댓글 없음:
라벨: , , , ,

HTTP Request


크게 GET, POST, 기타 방식이 존재


GET

가장 일반적인 HTTP Request 방식으로 요청 데이터에 대한 인수를 URL을 통해 전송함. URL에 인수가 그대로 나타나기 때문에 보안에 취약한 방식. GET 방식에서는 각 이름과 값을 &로 결함하며 글자수는 255자로 제한됨.


POST

GET과 달리 HTTP 헤더에 데이터를 전송. 내부의 구분자가 각 파라미터(이름, 값 등)를 구분하며, 서버를 이를 해석하며 처리해야하기 때문에 GET 방식보다 상대적으로 처리 속도가 늦음. 많은 양의 데이터를 전송하는 경우 사용.


기타

  • HEAD : 서버 측의 데이터를 요청하고 검색하는데 사용.
  • OPTIONS : 자원에 대한 요구/응답 관계에서 관련된 선택 사항의 정보를 요청할 때 사용.
  • PUT : 메시지에 포함되어 있는 데이터를 지정한 URI에 저장.
  • DELETE : URI에 지정되어 있는 자원을 서버에 지울 수 있게 함.
  • TRACE : 요구 메시지의 최종 수신처까지 루프백 검사에 사용.

reference

작성자: 시간: 댓글 없음:
라벨: , , , ,

10월 18, 2016

TCP 3-way handshaking, 4-way handshaking

  • SYN : 시퀀스 동기화 요청
  • ACK : 패킷을 받았다는 응답. 다음에 받을 시퀀스 넘버를 가지고 있음.
  • FIN : 연결 종료 요청



3-way handshaking: Connection establishment


  1. Step1

    2. Initiator[CLOSED]가 SYN(To Receiver)를 전송. Initiator는 전송한 SYN(To Receiver)에 대한 ACK를 기다리는 Initiator[SYN-SENT]로 전환.

  2. Step2

    3. Receiver[LISTEN]가 SYN(From Initiator)에 대한 ACK와 SYN(To Initiator)를 전송. SYN(To Initiator)에 대한 ACK를 기다리는 Receiver[SYN-RECEIVED]로 전환. Initiator[SYN-SENT]가 ACK(From Receiver)를 받으면 Initiator[ESTABLISHED]로 전환. 받은 SYN(From Receiver)에 대한 ACK를 전송.

  3. Step3

    4. Receiver[SYN-RECEIVED]가 ACK(From Initiator)를 받으면 Receiver[ESTABLISHED]로 전환. TCP 연결이 확립, 데이터 교환이 가능.



4-way handshaking: Connection termination

세 방향 핸드셰이크는 네트워크로 연결된 미디어를 통해 세 개의 패킷만 전송하면 되지만 이 신뢰성 있는 연결을 종료하려면 네 개의 패킷을 전송해야 합니다. TCP 연결은 데이터가 서로에 관계 없이 각 방향으로 흐를 수 있는 전이중이기 때문에 각 방향으로 개별적으로 전송해야 합니다.


  1. Step1

    2. Terminator[ESTABLISHED]가 FIN(From Terminator)를 전송. FIN(From Terminator)에 대한 ACK를 기다리는 Terminator[FIN-WAIT-1]으로 전환.

  2. Step2

    3. Receiver[ESTABLISHED]가 FIN(From Terminator)에 대한 ACK를 전송. 어플리케이션에게 close 알리고 Receiver[CLOSE-WAIT]로 전환. Terminator[FIN-WAIT-1]은 ACK(From Receiver)를 받으면, FIN(From Receiver)를 기다리는 Terminator[FIN-WAIT-2]로 전환.

  3. Step3

    4. Receiver[CLOSE-WAIT]는 어플리케이션이 close할 준비가 되면 FIN(To Terminator)를 전송. Fin(To Terminator)에 대한 ACK를 기다리는 Receiver[LAST-ACK]로 전환. Terminator[FIN-WAIT-2]는 FIN(From Receiver)를 받으면 ACK를 전송하고, terminating process 전에 전송되었을지 모르는 패킷을 기다리는 Terminator[TIME-WAIT]로 전환. 일정시간 동안 여분의 패킷을 기다린 후 연결 종료 Terminator[CLOSED].

  4. Step4

    5. Receiver[LAST-ACK]는 ACK(From Terminator)를 받으면, 연결을 종료 Receiver[CLOSED].



reference

작성자: 시간: 댓글 없음:
라벨: , , , ,

1월 03, 2016

네트워크 게임 튜토리얼 season1


  1. winsock의 개념

    2. 네트워크 게임 튜터리얼 1 - 워밍업

    1. winsock의 역사
    2. winsock의 종류

      • Window message select(WSAAsyncSelect)
      • Kernel event select(WSAEventSelect)
      • Overlapped I/O(Overlapped)
      • Overlapped I/O + IOCP (IOCP)

    3. Non blocking 개념
    4. Todo

      • Unix network programming, W. Richard Stevens
      • MFC
      • 소스 분석

    출처: http://www.gamedevforever.com/39, http://rhea.pe.kr/

  2. Network game architecture

    3. 네트워크 게임 튜터리얼 2 - 아키텍트 돋는 첫걸음

    1. Network architecture

      • C/S
      • P2P

        • Player 수 증가에 따른 복잡도 증가(O(n*n)), NAT, session migration 등 어려운 문제가 존재.

      • C/S vs P2P

    2. Network architecture case analysis

      • packet analysis tools
        • netstat
        • TCPView
        • WireShark
      • C/S example: poker game

        • 여러대의 서버가 sign in process, game lobby, in-game 등 역할을 나눠 각 process를 담당. 이외에

        • 서버간 통신을 담당하는 서버
        • 어떤 서버로 연결할지 알려주는 서버
        등이 필요.

      • P2P example: Battle.net

        • 세션 마이그레이션: P2P 연결에서 host가 나갔을 때, host를 옮기는 과정.
        • 유저 간 정보 교환은 UDP로.

    3. Hole punching

      4. NAT(Network Address Translator=공유기) 뒤에 있는 peer의 IP는 실제 IP가 아니기 때문에 server가 될 수 없음. 이를 해결하기 위해 hole punching 기법 사용.

    4. To do

    출처: http://www.gamedevforever.com/39, http://rhea.pe.kr/

  3. DB와 server 연결하기

    4. 네트워크 게임 튜터리얼 3 - 데이터베이스 그리고 C/S DB에 들어가는 내용

    • 유저 관련 정보: 가입, 탈퇴, 로그인, 친구, 기타등등..
    • 게임 컨텐츠: 레벨, 경험치, 아이템, 공격력...
    • 인벤토리: 아이템, 수량, 돈...
    • 몬스터 정보: 경험치, 레벨, 공격력..
    • 사용자 패턴 정보
    • 그 외 '정보'라 할만한 모든 것
    DB
웹서버 -------- 게임서버    DB가 웹서버와 게임 서버를 연결하는 역할
    1. DBMS 기초

    2. Winsock 과 ADO를 사용한 채팅 시스템
      1. DB 설계
      2. DB를 프로그램에 연결
      3. packet 설계

        4. 패킷 검출용 CGeneric class를 만들고 다른 패킷들은 이 클래스를 상속. DWORD head를 통해 패킷의 종류를 판별. 실제로 패킷을 전송 시엔 CDataMessage라는 버퍼용 클래스로 패킷을 감싸고 패킷의 크기는 버퍼클래스의 앞부분 4비트를 통해 표시.

    3. To do
      • 소스코드 분석
      • MySQL 문법 확인
    출처: http://www.gamedevforever.com/39, http://rhea.pe.kr/

  4. 로비 서버 만들기 -들어가기에 앞서: 객체의 생명주기, serialization, packet generator 등

    5. 네트워크 게임 튜터리얼 4 - 로비, 그리고 할말이 많다

    1. C/S의 생명주기

      2. 출처: http://www.gamedevforever.com/ 게임 서버는 Patch server, load balance server, lobby server, game server 등 분산 서버 구조를 이루고 있는데, 필요한 객체 생성 및 초기화 등은 이를 담당하는 서버에서 처리를 해야하고 lobby server는 lobby, game server는 game 등 자신이 담당한 역할에 집중할 수 있게 설계해야함.

    2. Lobby server 제작

      • Serialization

        • XML

          • 텍스트 기반으로 이뤄진 자료구조. 사람이 읽기 쉽지만 너무 커서 게임 서버에서는 잘 쓰지 않음. 멀티플랫폼 사용 가능

        • Protocol Buffer

          • 구글에서 만든 serialization protocol. 몇몇 기본 자료형과 string 만 보낼 수 있는 등 제약이 있음

        • JSON

          • Java script 용으로 나온 경량 데이터 교환 포맷. 가벼움. 멀티 플랫폼 가능.

        • boost::serialization

          • 강력한 기능: STL collection을 그대로 serialization. C++ 단일 플랫폼에 대해 사용 가능.

      • Packet generator 패킷 생성기

        • IDL 컴파일러: filename.idl 파일을 만들고 정해진 형식에 따라 필요한 함수를 작성해놓으면 이를 바탕으로 자동으로 소스 코드를 만들어주는 외부 컴파일러. 프라우드넷 IDL 컴파일러 등

    출처: http://www.gamedevforever.com/39, http://rhea.pe.kr/

  5. Serialization

    6. 네트워크 게임 튜터리얼 5 - 드디어 직렬화

    1. 패킷 정의

    2. 모든 패킷의 base class 패킷을 만들고 이를 상속하여 실제로 사용할 각 패킷을 작성. polymorphism과 overiding 기법을 사용.
    3. 각 유저를 구분하는 키는 string보다 int(혹은 long) 형이 성능 측면에서 유리함

    4. Boost.Acchive

      • Boost.Archive 클래스

        • 파일 스트림을 통해 파일에 읽고 쓸 수 있게 해주는 클래스. serialization을 담당하는 Boost.Serialize는 Boost.Archive 라는 유틸리티 클래스에 기반을 두고 있음. Archive는 serialize를 담당하는 text_oarchive 클래스와 deserialize를 담당하는 text_iarchive 클래스로 구분됨. 클래스 내부에 boost::archive::text_oarchive와 boost::archive::text_iarchive 형 객체를 선언하고 이를 통해 입출력 수행.

      • Boost.Serialize 클래스

        • 클래스 내부에 serialize 함수를 선언

    5. Asio.Serialization

      1. 패킷 클래스에 serialize 함수 추가
      2. serialization

    6. 더 해야할 것

      • 빌드 시 패킷 클래스에 자동으로 serialization 함수를 넣어주는 방법?
      • (위에 이어) 각 패킷 클래스별 수신 함수를 자동으로 만들어주는 방법?

    출처: http://www.gamedevforever.com/39, http://rhea.pe.kr/

  6. 참고

    7. Chapter 64. Boost.Serialization

작성자: 시간: 댓글 없음:
라벨: , , , ,
피드 구독하기: 글 (Atom)