networking

2가지로 나누어짐

  1. connection-oriented (연결지향) : 연결 후 통신
    ex) 전화, 카카오톡 - stateful - 1번의 연결 후 연결끊길 때까지 연결-요청-응답 과정 반복 (1회 연결, 여러 회 통신) - 적은 수의 client에게 대응 가능 - 현재의 통신 방식 - Thread 기술 : 여러 server를 두면 많은 수의 client에게 대응 가능
    ex) ssh(telnet + secure), FTP, chatting, google meet
    -stateless - 1번의 연결 후 연결-요청-응답 과정거치고 연결끊음 (1회 연결, 1회 통신) - 많은 수의 client에게 대응 가능
    ex) HTTP

  2. connectionless (비연결) : 연결없이 데이터 전송
    ex) 메시지, 방송

방송은 subnet에 있는 모든 IP에 쏘므로 group IP만 필요
ex) 172.0.4.0/24는 172.0.4를 가진 모든 IP
    172.0.4.0/16은 172.0을 가진 모든 IP

timeout : 특정 시간까지 안 주면 안 받음.

TCP : connection-oriented 방식 통신.

  • 데이터 전송에 대한 신뢰성있음.
  • HTTP1~2까지 TCP였음.
  • 연결할 때 3way handshake라는 3번의 연결 확인 과정이 필요하므로 느림

UDP : connectionless 방식 통신.

  • 데이터 전송에 대한 신뢰성없음. 신뢰성 확보위해 별도의 처리 필요.
  • HTTP3부터는 UDP임.
책 추천 : 모두의 네트워크

proxy server

: client와 server 중간에서 통신을 중재

  • local

    • client
    • proxy server
      ex) charles proxy
    • cache (임시저장소)

  • remote

    • server
  1. client가 proxy server에게 요청
  2. proxy server가 server에게 요청
  3. server가 proxy server에게 응답
    • cache가 proxy server로부터 응답data를 보관 -> 같은 자원을 요청할 때 보관된 data를 즉시 전달 -> network overhead를 줄임 -> 응답속도 개선
    • cache가 proxy server를 모니터링 (HTTP 통신을 살펴볼 수 있음) -> 요청/응답내용 감시 -> 보안 강화
  4. proxy server가 client에게 응답

실습 과정

  1. charles proxy 다운로드

  2. form/exam-01.html 파일을 우클릭해 live server 접속

  3. windows 터미널에서 ipconfig /all 입력

  4. 이더넷 어댑터 이더넷의 IPv4 주소를 복사해 live server 주소창의 IP주소 대신 입력

  5. 새로고침 후 GET 요청 페이지와 POST 요청 페이지를 접속하고 나타나는 exam01파일의 contents raw값들을 비교한다.

HTTP

web browser가 TCP를 사용해 web server에게 요청

web server는 딱 한 번 응답

Request과정

GET /html/form/exam02?name=aaa&age=11
path (자원의 주소) ? Query string (server에 보내는 data)

GET path?parameter명=parameter값&parameter명=parameter값

GET /~/a.html?name=~&age=~ HTTP/1.1
server: localhost:5500
user-agent: ~
accept : html,xhtml+xml,xml (좌측부터 우선 순위를 두어 요청)
accept-language : kr, us, ~
.
.
.
message-body

method/URI/a.html protocol/version <- request line
header (요청에 대한 보충 정보)
1. 요청헤더
2. 공통헤더
3. ntt헤더

post method일 때 보내는 data

URI (Uniform Resource Identifier)

  • URL (Uniform Resource Locator)
    ex) http://서버:포트/~/~/~
  • URN(Uniform Resource Name)
    ex)~:~:~

method가 GET 요청

  • data를 URL에 붙여 보냄
    • 한계
      1. URL은 URL encoding으로 text data로 바꿔야하므로 server에 binary data를 보낼 수 없다. -> binary data를 text data로 encoding하면 가능 (base64 규칙에 따라)
        ex) image
      2. URI 크기의 제한때문에 대용량 data를 보낼 수 없다.
      3. URL -> browser cache에 보관하므로 보안이 안된다.
  • content-type이 없다.
<img src="https://static.vecteezy.com/packs/media/vectors/term-bg-1-666de2d9.jpg">

<img src="data:image/jpeg;base64,/9j/4AAQSkZ~>


POST /~/a.html HTTP/1.1
host: 192.168.x.x:5500
content-length: 15
content-type (my type): application/~~
user-agent: ~
accept : html,xhtml+xml,xml (좌측부터 우선 순위를 두어 요청)
accept-language : kr, us, ~
.
.
.
name=aaa&age=13

method/URI/a.html (query string없다.) protocol/version <- request line
header (요청에 대한 보충 정보)
1. 요청헤더 (content-length, content-type)
2. 공통헤더
3. ntt헤더

message-body

method가 POST 요청

  • URL에 요청하지 않고 별도의 payload (전송되는 data)에 정보를 담아 요청
  • binary data 전송 가능
  • URL에 노출 안 됨 -> URL에 data를 포함해야 하는 경우 (검색URL, 게시글 조회URL)에 적합하지 않다.
  • 여러 개의 파일 첨부 가능
  • 용량 제한없다.
  • content-type이 있다.

text

  • 일반 text editor로 편집 가능한 format
    ex) .txt, .rtf, .html, .css, .js, .xml, .json, .properties, .java, .py, .docx (원래 ms word 전용인 binary data였지만 국제 표준이 되기 위해 xml 형식으로 읽을 수 있도록 변형)

binary

  • byte 단위로 형식이 format
  • 일반 text editor로 편집 불가 (format이 깨짐)
  • 전용 app 사용
    ex) .mp3, .mp4, .jpg, .png, gif, .avi, .doc
메모리 -> 01000001 -숫자-> 65
메모리 -> 01000001 -문자(url encoding)-> 0x41 -> A

메모장에서 binary를 출력할 순 있지만 처음부터 다른 의미로 저장했으므로 text data가 아님

HTTP/1.1 200 ok
content-length: 2242 (bytes) (content 크기가 2242byte)
content-type (my type): text/html; charset=UTF-8 (html로 응답)
.
.
.
<!DOCTYPE HTML>
<HTML>
.
.
.
</HTML>

protocol/version 상태 코드값 상태에 대한 설명 <- status line
header (응답에 대한 부연 설명)
1. 응답헤더
2. 공통헤더
3. ntt헤더

message body