Proxy & Network 퀴즈

출처

• 정글 사관학교

---

 

1. client-server model에 대해서 설명하시오

[위키백과] 서비스 요청자인 client와 서비스 자원의 제공자인 server 간에 작업을 분리해주는 분산 애플리케이션 구조이자 네트워크 아키텍처를 나타낸다.

 

2. HTTP request와 response에 대해 아는대로 설명하시오 [mdn]

HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식. 메시지 타입에는 요청과 응답이 있다. 요청은 클라가 서버로 전달해 서버의 액션이 일어나게끔 하는 메시지이고, 응답은 요청에 대한 서버의 답변이다.

 

+ 첨언) GET request도 body 가 있을 수 있다. 단, RFC-9110 에서는 GET request body를 만들지 않도록 권장하고 있다. 현재 QUERY emthod를 추가하자는 주장이 나오고 있다고 [출처]

 

 

3. HTTP status code에 대해 아는대로 말하시오

[RFC9110: status-codes]

[RFC1945: Status Code Definitions]

 

응답 상태코드는 요청 결과에 대해 3자리 정수로 표현하고 semantic (의미론적) 하다. 첫번째 자리는 응답 유형을 나타낸다. 나머지 두자리는 규칙이 없다.

• 1xx (Informational): 요청을 받았고, 처리 과정이 계속 진행 중
  • 대용량 파일을 업로드할 때처럼 더 많은 데이터가 필요하거나,
  • 서버가 최종 응답 전에 클라에게 진행 상황을 알리기 위해
• 2xx (Successful): 요청을 올바르게 처리되었을 때
  • 가장 흔한 응답은 200 OK, 새로운 리소스 생성 (201), 비동기 처리 (202), 반환할 콘텐츠가 없는 경우 (204)
• 3xx (Redirection): 요청을 정상적으로 수신했지만 추가적인 작업이 필요함을 나타냄
  • 301 Moved Permanently : 리브랜딩으로 신규 도메인으로 영구적으로 이동했음. SEO 측면에서는 검색 엔진이 새 URL을 인덱싱하고 기존의 SEO 가치를 그대로 유지할 수 있음 
  • 302 Found (Moved Temporarily): 일시적인 점검 및 A/B 테스트와 같이 추후 다시 원래 페이지로 돌아올 수 있을 경우, 브라우저가 새로운 URL 을 캐싱하지 않음
• 4xx (Client Error): 클라 요청이 잘못됨.
  • 401 : 인증 (로그인) 이 필요함
  • 403 : 인증은 되었지만, 권한이 없어 인가되지 않음
• 5xx (Server Error): 서버가 내부적 오류를 맞딱드리거나 유효한 요청을 처리할 수 없는 상태

 

• 궁금증 : 1xx vs 3xx
  • 1xx : 서버가 아직 요청을 처리 중이고, 클라가 추가 데이터를 전송하거나 현재 작업의 일부분을 계속 진행해야함
  • 3xx : 클라는 다른 URL로 요청을 보내서 완전히 새로운 작업을 수행해야함

 

4. web browser/client에서 http://www.myserver.com:8080/index.html 를 요청했을 때 network 및 client 에서 어떤 일이 일어나는지 아는대로 설명하시오

• URI를 parse하면, protocol=http, host=www.myserver.com, port=8080, path=/index.html 업데이트
• www.myserver.com 의 IPv4 address를 알기 위해 설정된 name server로 DNS A record qeury
• name server의 답변으로 알게 된 IP address의 8080 port로 TCP/IP connection 시도
• GET /index.html HTTP/1.1 로 시작하는 HTTP request message를 전송하고 응답을 기다림
• HTTP response의 status code가 200 OK 이면, body를 Content-length 만큼의 byte 를 읽어와 Content-Type과 함께 browser의 renderer로 전송
• status code가 4xx 혹은 5xx 이면 정해진 error message를 렌더링해서 출력

 

5. CS:APP 12장 동시성 프로그래밍에서 소개한 다중 프로세스, I/O 멀티 플렉싱, 다중 스레드 중 하나를 사용해야했다.

5-1) 동시성을 구현하지 않은 서버는 어떤 문제점이 있고 왜 동시성이 필요한지 설명하고, 

• 동시성을 구현하지 않은 서버는 accept 이후 접속한 client와의 연결을 close 하기 전까지 다시 accept를 수행하지 않음. 따라서 한 client의 요청을 처리하는 동안 다른 client의 요청은 accept 될 때까지 기다리게 됨. 두번째 이후 client 입장에서는 응답을 받은 시각이 요청한 시각보다 꽤 늦어지므로 응답시간이 길어짐. 어차피 listen fd와 (accept가 return한) connect fd가 다르므로 connect fd를 처리하는 동안 accept를 계속 수행할 수 있다면 응답속도 향상을 꾀할 수 있음. 즉, 연결을 받는 accept과정과 요청을 처리하는 과정을 분리함으로써 응답속도 및 동시 처리량을 늘리는 것을 기대할 수 있음.

 

5-2) 위 각각의 방법에 대해서 아는 대로 기술하라. 비교하거나 장단점을 나열할 수 있으면 더 좋다.

• 2a. multi-process 요청이 들어올 때 마다, 즉 connect fd가 새로 생길 때 마다 process를 생성하여 새 process가 요청을 처리하고, 원래 process는 새 요청을 받도록 분업하는 방식. process 생성은 fork() syscall을 사용하는데, fork는 프로세스 전체를 복사하므로 내가 parent인지 child인지 fork()의 return 값으로 구분하여, parent이면 connect fd를 닫고 accept로 돌아가고, child이면 listen fd를 닫고 connect fd를 read/write 하여 요청을 처리한다.
  • process는 독립적이고 보호받는 memory 공간을 생성하므로 thread에 비해 안전하긴 하나 process 생성/소멸에 시간이 많이 든다.
• 2b. multi-thread multi-process와 유사하게 새 요청이 들어올 때 마다 thread를 생성하여 새 thread가 요청을 처리하도록 분업하는 방식. thread 생성 방법은 여러가지 방법이 있으나 POSIX 표준인 pthread_create를 사용하면 대부분의 OS에서 compile 가능하다. pthread_create()는 생성되는 thread가 수행할 function 및 그 argument를 지정할 수 있으므로 요청 처리 부분을 별도 function으로 작성하고 connect fd를 argument로 넘겨받을 수 있다.
  • thread 방식은 여러 thread가 같은 memory 공간을 사용하므로 race condtion에 대비하여야 한다. lock, semaphore, monitor 등이 필요하다.
• 2c. I/O multiplexting 서버 처리에 동시성이 필요한 이유는 I/O 시간이 연산시간보다 매우 길다는 것이 문제이다. 즉, read/write call이 완료되기까지 기다리는 시간이 길다는 것이 문제이며, 이 시간동안 다른 처리를 할 수 있다면 전반적인 성능을 향상할 수 있다. 그래서 read/write를 수행하기 전에 select()로 해당 fd에 read 혹은 write를 수행하면 바로 처리할 수 있는지 확인하고 read/write를 수행하는 방법이 있다. 즉, select를 사용하여 하나의 listen fd와 요청 수 만큼의 connect fd를 다 같이, I/O가 완료되는 대로 처리를 하도록 만들 수 있으므로 불필요한 I/O 대기 시간 없이 처리가 가능하다. fcntl()을 사용하여 해당 fd를 non-blocking I/O로 설정하면 read/write call시 대기해야 되는 상황이 되면 프로세스가 잠들지 않고 바로 error가 return이 되므로 좀 더 효율적으로 대처할 수 있다. 각 방법은 다음과 같은 장단점이 있다.
  • process/thread 방식은 I/O scheduling을 OS의 scheduler에게 맡기는 방식이므로 특정 I/O scheduling 방식을 구현할 수 없다.
  • select를 사용하는 I/O multiplexing 방식은 I/O scheduling을 다양한 방법으로 할 수 있고 process/thread의 context switch 비용이 없으므로 성능이 좋으나 코드가 매우 복잡해서 오류를 수정하기가 매우 어렵다.
  • I/O multiplexing 방법은 select 외에 poll, epoll, kqueue등이 개발. multiplexing을 위한 code가 너무 복잡하므로 event driven 방식의 코드 구조로 발전하게 되고, 이것은 뒤의 asynchronous I/O로 발전한다.
    • 추가로 읽어볼 것 
    • https://en.wikipedia.org/wiki/C10k_problem
    • http://www.kegel.com/c10k.html

 

[참조: CS:APP 12장]

 

6. multi-process와 multi-thread에 대해서 좀 더 자세히 비교하라. process와 thread 모델의 차이를 설명하고 - 구체적으로 어떤 함수를 사용하여 새로운 프로세스/스레드를 만들며 - 생성된 프로세스/스레드가 끝나는지를 생성한 프로세스/스레드가 어떻게 감지하는지도 설명하라 - HTTP/proxy 서버가 새로운 request를 받을 때, response가 끝날때 어떻게 처리되는지도 설명할 수 있으면 좋다

• process는 컴퓨터를 추상화 한 것, thread는 CPU core를 추상화 한 것
• process간 공유하는 것 없음, thread는 stack을 제외한 memory 공간 공유
• fork() vs pthread_create(tid, attr, func, arg) - wait(wstatus) vs pthread_join(thread, retval)
• fork 후 필요없는 fd close vs thread 함수에 fd 넘겨준 후 detach

 

7. OSI reference model (7 layer) 각 계층 이름과 역할을 설명하시오. HTTP 하단 layer 들을 아는대로 말하고 어떤 reference layer에 해당하는지 논하시오.

• Application - HTTP
• Presentation - MIME type
• Session - Cookie, TCP connection
• Transport - TCP
• Network - IPv4, IPv6
• Data Link - Ethernet (IEEE 802.2), WiFi (IEEE 802.11), LTE, 5G, PPP, SLIP
• Physical - UTP(Unshielded Twisted Pair) cable, RJ45(8P8C), Coaxial cable, BNC, RS-232C

 

8. 이번 프로젝트에서 네트워크 입출력에 대해서는 표준 입출력 함수를 쓰지 않고 RIO 함수들을 사용하였다. RIO 함수를 사용했어야 하는 이유, 즉 RIO 함수들을 만든 이유를 아는 대로 설명하시오

client 쪽에서 write 한 번에 여러줄의 text를 보냈다 하더라도 server의 read에서는 한 줄이 다 읽히지 않을 수도 있음. (packet이 다 도착하지 않은 상태에서 write call이 끝날 수도 있으니까) 또한 3800 byte를 보내라고 했는데 실제로는 1500 byte만 보내고 못 보낼 수도 있음 (write()가 실제로 보낸 byte 수를 return하는 이유가 이것임) 이와 같이 다양한 예외조건을 일일히 고려하지 않도록 library를 만들어 둔 것임.

[참조: CS:APP 10.4, 10.5]

 

9. HTTP/1.0과 HTTP/1.1의 차이에 대해 아는대로 자세하게 설명하시오 가능하다면 HTTP/2, HTTP/3 에 대해서도 설명하시오

• HTTP/1.1 의 request에는 Host header가 꼭 있어야 함
• HTTP/2는 TLS가 필수이며 multiplexing등 각종 성능 향상 기능이 아래 layer로 구현됨
• HTTP/3는 UDP기반의 QUIC protocol위에서 HTTP를 사용할 수 있도록 구현되어 낮은 latency가 필요한 경우 사용할 수 있음