다운로드를 받아보자 ~ 음 확장자가 숨겨져있다. 역시 이럴땐 만만한게 메모장!! 메모장으로 열어서 내용을 확인해보니 Request 등등의 패킷정보가 있다. 패킷파일이라고 의심되어 와이어샤크로 해당 파일을 열어봤다. 정확했다. 패킷들을 Export하고 확장자를 땐 파일이였다. 살펴보니 TCP 통신에 대한 패킷들이 있어서 stream별로 분리해서 살펴보았다. PNG라고 보이는가? 뭔가 다운로드 받는 모양이여서 해당 패킷들의 내용을 Export한 후 살펴보기로 했다. File-Export Objects-HTTP를 사용해 파일을 Exports 하려고보니 index.html도 보이고 해서 그냥 전부다 Export 해버렸다 !! 그리고 난 후 index.html을 눌러 내용을 확인해봤다. 이런 형태의 html이 나..
Fragments ? IP 프로토콜은 IP 패킷을 몇 개의 작은 패킷으로 나누어 전송한 후, 목적지에서 재조립 할 수 있다. 라우터가 판단해서 보내려는 패킷의 크기가 출력측 LAN, 통신회선이 처리할 수 있는 크기보다 크다면 IP 패킷을 나누어서 전송하게 된다. MTU ? IP 패킷이 네트워크를 통해 전송될 때 전송될 수 있는 IP 패킷의 최대 크기. (기본적으로 1500Byte - Header포함) IP 패킷의 크기가 MTU보다 클 때 IP Fragments가 발생하게 된다. (대신 애플리케이션 등이 패킷을 분할 불가로 저장한 경우 또는 이미 분할된 경우에는 분할할 수 없다.) 위 사진과 같이 라우터 통과시 분할되어 전송된다. 그리고 목적지에 도착해서 분할되어 전송됬던 패킷이 재조립과정을 거치게 되는데..
TCP 통신에서 윈도우 제어 방식을 통해 효율적인 ACK 번호를 관리한다. 패킷을 전송한 후 수신자로부터 ACK 이 돌아올 때 까지 기다리는 것은 시간낭비다. 이 시간낭비를 아예 없애진 못하고 최소화 하기위해서 윈도우 제어 방식을 고안했다. 동작 방식은 이렇다. 수신사가 수용할 수 있는 데이터 크기(Window Size)를 송신자에게 보낸다. Three-way Handshake 과정에서 보내기 때문에 통신 전에 송신자에게 Window Size에 대한 정보가 들어온다. 그리고 송신자는 수신자에게 Window Size가 넘지 않을 만큼의 패킷을 계속해서 보낸다. 여기서 중요한 점은 여러개의 패킷을 보내도 ACK이 돌아오지 않는다는 점이다. ACK이 돌아오지 않아도 송신자는 자기가 보낸 Data Size에 따..
ACK ? 기본적으로 ACK은 TCP Header에 포함되어있는 4Byte크기의 정수 데이터이다. TCP 통신에서 ACK은 패킷 도착여부를 확인 하기위해 사용된다. 위 사진과 같이 수신한 패킷의 Sequence Number와 Data의 크기에 따라 ACK 번호가 결정되게 되는데 결정할 때 사용하는 공식은 "SEQ + (Data Size)" 이다. 그러나 여기서 반드시 기억해야 할 점은 Data Size가 0이라면 같은 ACK을 반복하게 된다. 이 것을 방지해서 받은 패킷의 Data Size가 0이라면 Sequnce 번호에 1을 더한 값을 ACK으로 설정한 후 패킷을 전달하게 된다. ( 물론 위 그림은 A가 B에게 패킷을 전달하는 과정이고, 원래는 양방향으로 전달하기 때문에 서로 SEQ, ACK, Data..