스미스요원

프로세스란 종단 시스템, 즉 어플리케이션 계층에서 실행되는 프로그램을 의미한다.

그럼 프로세스 간의 통신은 언제 일어날까?

먼저 통신 프로세스가 동일한 어플리케이션 계층에서 실행될 때 발생한다.

같은 계층 안에서 프로세스간에 이루어지는 통신은 어플리케이션 계층, 즉 종단 시스템의 운영체제에 따라 그 방식이 결정된다.

두번째로 서로 다른 어플리케이션 계층 간에도 프로세스 통신이 발생할 수 있다.

서로 다른 2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통해 메시지(message)를 교환하는 방식으로 통신한다.

송신 프로세스가 메시지를 만들어 네트워크로 보내면, 수신 프로세스는 메시지를 받아 다시 그에 대한 응답 메시지를 보내는 식이다.

네트워크 통신에서  프로세스 간 통신이라 하면, 주로 이렇게 서로 다른 어플리케이션 계층 간의 통신을 의미한다.

이번 포스팅에서는 네트워크 통신에서의 프로세스 간 통신에 대해 알아보자.

클라이언트 프로세스 & 서버 프로세스

이전 포스팅에서 클라이언트 - 서버 어플리케이션 구조에서는 클라이언트끼리 직접적으로 통신하는 것이 아니라, 서버가 클라이언트와

클라이언트 사이에서 중재자 역할을 하며, 클라이언트가 보낸 데이터를 다시 다른 클라이언트에게 전달해 준다는 내용을 살펴보았다.

이 때 클라이언트가 바로 클라이언트 프로세스를 의미하고, 서버가 서버 프로세스를 의미하며,

클라이언트와 서버 사이를 왔다갔다 하는 데이터가 바로 메시지를 의미한다고 이야기할 수 있다.

즉 클라이언트 브라우저 프로세스가 웹 서버 프로세스와 메시지를 교환하는 경우,

브라우저는 클라이언트 프로세스이고, 웹 서버는 서버 프로세스인 것이다.

P2P 구조에서 피어(peer) 역시 하나의 프로세스라고 할 수 있는데, 이 때 피어는 클라이언트 프로세스가 될 수도 있고,

동시에 서버 프로세스가 될 수도 있다. 

이런 경우 클라이언트 프로세스와 서버 프로세스는 다음과 같이 분리된 개념으로 보면 편하다.

• 클라이언트 프로세스 : 두 프로세스 간의 통신 세션에서 통신을 초기화하는 프로세스

                                      (다른 프로세스와 세션을 시직하기 위해 접속을 초기화 시킴)

• 서버 프로세스 : 세션을 시작하기 위해 접속을 기다리는 프로세스

웹 브라우저는 웹 서버와 접촉을 초기화한다.

따라서 브라우저 프로세스는 클라이언트 프로세스이고, 웹 서버 프로세스는 서버 프로세스이다.

P2P 파일 공유 어플리케이션에 피어 A, B 가 있다고 가정하자.

A 가 B 에게 특정 파일을 보낼 것을 요청하는 경우 A 는 클라이언트 프로세스, B 는 서버 프로세스이다.

반대로 B 가 A 에게 특정 파일을 보낼 것을 요청하는 경우 다시 B 가 클라이언트 프로세스, A 가 서버 프로세스가 된다.

쉽게 말해 요청을 보내는 쪽이 클라이언트, 요청을 받고 응답을 보내주는 쪽이 서버이다.

소켓 between 프로세스 & 컴퓨터 네트워크

대부분의 어플리케이션은 메시지를 주고 받는 두 통신 프로세스의 쌍으로 구성된다.

이 때 두 프로세스간의 메시지는 인터넷, 즉 네트워크를 통해 움직이며, 프로세스는 소켓(socket)을 통해 네트워크로 메시지를 보내거나 받는다.

쉽게 말해 프로세스는 집 이고 소켓은 출입구이며, 메시지는 출입구를 통해 집을 빠져 나간다고 볼 수 있다.

지난 포스팅에서 살펴본 OSI 7 계층을 떠올려 본다면,

소켓은 어플리케이션 계층과 트랜스포트 계층 간의 인터페이스 이며, API 라고 이야기할 수도 있다.

이 때 어플리케이션 개발자는 어플리케이션 계층에 대해서는 모든 통제권을 가지나, 트랜스포트 계층에 대해서는 그렇지 않다.

트랜스포트 계층에 대해 어플리케이션 개발자가 조작할 수 있는 것은 트랜스포트 프로토콜을 선택하는 것과,

최대 버퍼/세그먼트 크기 등의 매개변수를 설정하는 것 뿐이다.

어플리케이션은 개발자가 선택한 트랜스포트 프로토콜이 제공하는 전송 서비스를 사용하여 구성되는데,

이 트랜스포트 프로토콜에 대해서는 이후 포스팅에서 좀 더 자세히 알아보도록 하자.

프로세스 주소 : IP 주소와 포트 넘버

이전 포스팅에서 클라이언트-서버 구조를 다룰 때 고정 IP 주소의 개념을 간단하게 살펴본 적이 있었다.

프로세스간에 메시지를 주고 받기 위해서는 두가지 정보가 필요한데, 그 중 하나가 IP 주소이고,

나머지 하나는 IP 주소가 가리키는 목적지 호스트 안에서 통신에 참여하고 있는 프로세스의 식별자이다.

호스트 안에 여러개의 프로세스가 존재할 수 있기 때문에, 그 중 어떤 프로세스가 메시지를 보냈는지 알기 위해 식별자가 필요하고

포트 넘버(port number)가 바로 이 프로세스를 식별하는데 사용된다.

자주 사용되는 어플리케이션에는 보통 약속처럼 정해진 포트 넘버가 할당되는데,

예를 들어 웹 서버는 포트 넘버 80번으로 식별되고, SMTP 프로토콜을 사용하는 메일 서버는 포트 넘버 25번으로 식별된다.

인터넷 표준 프로토콜들이 이렇게 약속처럼 정해두고 사용하는 포트 번호 리스트는 여기에서 찾아볼 수 있다.

참고자료

네트워크 어플리케이션 구조란 이전 포스트에서 다룬 OSI 7 계층 구조 같은 네트워크 구조와는 다른 개념이다.

어플리케이션 개발자 관점에서 네트워크 구조는 고정되어 있는 구조인 반면, 네트워크 어플리케이션 구조는
어플리케이션 개발자가 직접 여러 구조 중 하나를 선택하고, 세부적으로 설계해야하는 구조라 할 수 있다.

이번 포스팅에서는 가장 많이 사용되는 대표적인 네트워크 어플리케이션 구조 두가지에 대해 알아보자.

클라이언트 - 서버 구조 (Client-server Architecture)

• 서버(server) : 항상 켜져있는 호스트

• 클라이언트(client) : 가끔 혹은 항상 켜져있을 수 있음

• 서버는 클라이언트 라는 다른 많은 호스트로부터 요청(Request)을 받는다.

    ◦  예 ) 클라이언트 호스트에서 실행되는 브라우저가 항상 켜져있는 웹 서버로 서비스를 요청한다.

                이 때 웹 서버는 클라이언트 호스트로 요청받은 객체를 보내어 응답한다.

    ◦  즉 서로 다른 브라우저가 상호간에 직접적으로 통신하지 않는 것 처럼,

         클라이언트 - 서버 구조에서 클라이언트 끼리는 서로 직접적으로 통신하지 않고, 무조건 서버를 거친다.

• 고정 IP 주소 : 서버는 고정 IP 주소라는 잘 알려진 유일한 주소를 갖는다.

    ◦  인터넷에서 호스트는 IP 주소로 식별된다.

    ◦  서버는 항상 동작하고 있으므로, 클라이언트는 이 서버 주소로 패킷을 보내서 항상 서버에 연결할 수 있다.

• 때때로 하나의 서버 호스트가 자신의 모든 클라이언트로부터의 요청에 응답하는것이 불가능한 경우도 있다.

    ◦  하나의 서버 호스트가 감당할 수 있는 정도 이상으로 요청이 들어오면 서버가 정상적으로 작동하지 못할 수 있음

    ◦  이런 문제를 해결하기 위해 데이터 센터가 사용된다.

• 데이터 센터(data center) : 많은 수의 호스트를 갖춘 강력한 가상의 서버

    ◦  데이터 센터는 전력이 공급되어야 하는 10만개 정도를 서버를 가지며, 서비스 제공자들은 데이터 센터로부터 데이터를 보내기 위해

         상호연결 및 대역폭에 대한 비용을 지불해야 한다.

    ◦  구글 같은 검색엔진이나 페이스북, 인스타그램 같은 SNS 등의 인기 있는 서비스들은 모두 하나 이상의 데이터 센터를 사용한다.

P2P 구조

• P2P 구조에서 어플리케이션은 클라이언트 - 서버 구조와 달리, 항상 켜져있는 호스트 서버에 거의 혹은 전혀 의존하지 않는다.

    그 대신 피어(peer)라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신한다.

    ◦  피어(peer) : 서비스 제공자가 소유하는 것이 아닌, 사용자들이 제어하는 데스크탑/랩탑 등을 의미

• 특정 서버를 경유하지 않고, 피어끼리 직접 통신하므로 이 구조를 피어-투-피어(P2P)라 부른다.

• 비트토렌트(BitTorrent), 스카이프 등의 서비스가 P2P 구조를 사용한다.

• 자가 확장성(self-scalability) : P2P 구조의 가장 주목할만한 특성

    ◦  New peers bring new service capacity.

    ◦  P2P 파일 공유 어플리케이션에서 여러 피어들이 파일을 요구하면 작업 부하가 발행하지만,

       각 피어들은 동시에 다른 피어들에게 파일을 분배해줄 수 있으므로 시스템 서비스 기능에 기여할 수 있다.

• 비용 효율성 : P2P 구조는 서버 기반 구조 및 서버 대역폭을 요구하지 않기 때문에 클라이언트 - 서버 구조 혹은 데이터 센터와

   비교해보았을 때 비용적인 측면에서 효율적이다.

• 그러나 P2P 특유의 분산 구조 특성으로 인해 보안, 성능, 신뢰성 부분에서 여러 단점이 존재한다.

참고자료

네트워크 이론을 공부할 때 반드시 마주치게 되는 개념이 있다. 바로 OSI 7 Layers 이다.
이 용어가 무엇을 의미하는지, 각 레이어는 무엇으로 이루어져 있는지 간단하게 살펴보자.

일단 컴퓨터 네트워킹이라는 개념은 아주 광대하고 복잡하다.
전 세계에 퍼져있는 거대한 인터넷망에 대한 이론이 상당히 심플하게 정리될 수 있다면 그거야말로 초-신기술일 것이다.
하지만 그런 마법같은 일은 일어나지 않았고, 개발자들은 이 복잡한 개념을 어떻게 정리해야 할지 고민한 결과,

네트워크 구조는 총 7가지의 계층 구조로 나누어지게 되었다.

그 결과, 거대한 네트워크 통신이 일어나는 과정을 단계별로 파악할 수 있게 되었고
네트워크 통신 규칙 및 통신 기술도 이러한 계층 구조에 기반하여 만들어지기 시작했다.

이에 따라 7개의 레이어 중 특정한 곳에 이상이 생기면 다른 단계의 장비 및 소프트웨어를 건들지 않고도
이상이 생긴 단계만 고칠 수 있게 되니 기술의 생산성이 높아졌고, 통신 기술은 점점 빠르게 발전할 수 있었다.

OSI 7 계층

OSI 7 계층은 위 그림과 같이 총 7개의 레이어로 이루어져 있다.

사용자가 데이터를 다른 누군가에게 보내면, 해당 데이터는 각 레이어를 거치며 제각기 다른 형태로 감싸져 다음 레이어로 전달된다.
7번째 계층부터 차례대로 각 계층의 의미와 역할을 간단하게 살펴보자.

7 Layer : Application Layer (응용 계층)

• 네트워크 상에서 데이터가 이동할 때 가장 끝과 끝에 위치한 목적지라고 볼 수 있다.
   - 예를 들어 A가 B에게 편지를 보낸다고 할 때, A가 보낸 편지는 A의 집에서 시작되어 우체국을 거치고, 도로 위를 이동하고,
       우편 배달부의 손을 거쳐 최종적으로 B의 집에 도착한다면 A의 집과 B의 집이 Application Layer에 해당한다.

• 네트워크 소프트웨어의 UI 부분 및 사용자의 입출력(I/O) 부분을 담당한다.

• 어플리케이션 계층 프로토콜

   -  HTTP(웹 문서), SMTP(전자메일), FTP(파일) 등 다양한 프로토콜을 포함한다.

   -  특정 위치에 있는 어플리케이션이 다른 위치에 있는 어플리케이션과 데이터를 교환할 때 이 프로토콜이 사용된다.

• 네트워크 어플리케이션

   -  어플리케이션 계층에서 생성되는 데이터는 메시지(message) 라고 불린다.

   -  이러한 메시지들은 어플리케이션 계층 프로토콜에 의해 처리되며, 우리가 사용하는 브라우저나 메일 프로그램 등은
      프로토콜을 보다 쉽게 사용하게 해주는 응용프로그램이다.

   -  메시지는 또 다른 어플리케이션 계층까지 전해지기 위해 바로 다음 계층인 Transport Layer로 전달된다.

6 Layer : Presentation Layer (표현 계층)

• 표현 계층은 데이터 표현 형식이 서로 다른 어플리케이션끼리 통신할 때 서로의 데이터를 해석할 수 있도록 해주며,
    데이터 해석 외에도 데이터 압축, 데이터 암호화 등의 작업을 담당한다.

   -  예를 들어 EBCDIC로 인코딩된 문서 파일을 ASCII 파일로 바꿔 주는 것,
       데이터가 TEXT 인지, GIF 인지, JPG 인지 구분하는 것 등이 표현 계층이 수행하는 역할이다.

• 표현 계층이 이러한 서비스를 제공해주기 때문에 어플리케이션 단계에서는 데이터가 표현 및 저장되는 형식을 신경쓰지 않아도 된다.

5 Layer : Session Layer (세션 계층)

• 데이터가 통신하기 위한 논리적인 연결이 이루어지는 계층이다. 쉽게 말해 통신이 맺어지는 관문이라고 할 수 있다.

• 세션 설정, 유지, 종료, 전송 중단시 복구 등의 기능을 수행하며 TCP/IP 세션의 생성과 소멸 작업을 책임지고 담당한다.

• 통신을 관리할 수 있는 기능으로 동시 송수신 방식(duplex), 반이중 방식(half-duplex), 전이중 방식(Full Duplex) 등을 제공하며

    통신 체크 포인팅 작업, 그리고 유휴/종료/다시 시작 등의 상태에 대한 작업을 수행한다. 

4 Layer : Transport Layer (전송 계층)

• 어플리케이션 레이어(4~7 계층)에서 만들어진 메시지를 클라이언트 단에서 서버로 전송하는 역할을 담당하는 계층이다.

    -  A가 B에게 편지를 보내려면 편지를 우체통에 넣어야 한다. 이 때 A가 쓴 편지가 어플리케이션 레이어에서 만들어진 메시지라면,
       편지를 우체통에 넣는 행위가 메시지를 서버에 올리는 작업이라고 할 수 있다.

• 즉 통신을 활성화시키는 계층이며 포트를 열어 응용프로그램이 데이터를 전송 할 수 있도록 연결을 맺는 역할을 수행한다.

• 어플리케이션 레이어에서 메시지를 받아 Transport 레이어에서 한번 더 감싸는 작업을 거치면 해당 데이터는 세그먼트(Segment)
    라고 불리게 된다. 이 데이터는 다시 바로 다음 계층인 Network 레이어로 전달된다.

• 만약 어플리케이션 레이어에서 데이터가 여러 개 도착했다면 전송 계층에서 이를 하나의 세그먼트로 모아 다음 계층에 전달한다.

• Transport Layer에는 TCP 와 UDP 라는 Transport Protocol 이 존재한다.

• 이 두가지 통신 규약을 통해 사용자들은 데이터가 신뢰할 수 있고, 손상되지 않은 데이터임을 보장받을 수 있다.

• Transport Layer가 존재함으로써 해당 계층의 상위 계층들은 데이터 전달의 유효성이나 효율성을 신경쓰지 않아도 된다.

• TCP (Transmission Control Protocol)

    -  연결 지향형 서비스 : 연결 관리를 위한 연결 설정(3 way handshake) 및 연결 해제(4 way handshake)가 필요하다.

    -  신뢰성 있음 (Reliable) : 패킷의 손실, 중복, 순서바뀜 등이 없도록 보장한다.

    -  Network 레이어로 세그먼트를 보낼 때 제대로 전달 되었는지 확인하고, 전송에 실패한 경우 재전송한다.

• UDP (User Datagram Protocol)

    -  TCP와 달리 비연결적인 접속 상태로 통신하며, 신뢰성이 없고 순서화되지 않은 서비스를 제공한다.

        ◦  메세지가 제대로 도착했는지 확인하지 않는다 : 확인 응답 없음

        ◦  수신된 메세지의 순서를 신경쓰지 않고 전송한다 : 순서 제어 없음

        ◦  흐름 제어를 위한 피드백을 제공하지 않는다 : 흐름 제어 없음

        ◦  checksum 을 제외하면 특별한 오류 검출 및 제어가 없다.

    -  그 대신 실시간 응용 및 멀티캐스팅이 가능하므로 빠른 요청과 응답이 필요한 실시간 서비스에 적합하다.

        ◦ 멀티캐스팅 : 여러 다수 지점에 데이터를 동시 전송하는 것 (1:多)

    -  또한 TCP가 세그먼트 헤더로 20 바이트를 사용하는데 비해 UDP는 8 바이트만 사용하므로 헤더 데이터 처리에 소요되는 비용이 적다

3 Layer : Network Layer (네트워크 계층)

• Transport Layer 에서 전달된 세그먼트는 네트워크 계층 내에서 패킷(packet)이라는 이름으로 불린다.

• 이 계층에서 가장 중요한 기능은 데이터그램을 목적지까지 안전하고 빠르게 전달하는 기능(라우팅)이다.

    -  즉 목적지로 데이터를 보낼 수 있는 가장 빠른 경로를 선택하고, 경로를 따라 패킷을 전달하는 것이 이 계층의 역할이다.

• IP 프로토콜

    -  IP 데이터그램의 필드를 정의하며 라우터가 이 필드에 어떻게 작용하는지를 정의한다.

• 라우팅 프로토콜

    -  출발지와 목적지 사이에서 패킷이 이동하는 경로를 결정한다.

    -  네트워크 레이어는 여러개의 라우터(패킷 스위치)를 통해 패킷을 전송하고,
        라우터를 하나 지날 때 마다 데이터를 가장 빠르게 전송할 수 있는 라우터를 재탐색하며 경로를 만들어 나간다.

2 Layer : DataLink Layer (데이터링크 계층)

• 앞서 Network Layer는 출발지와 목적지 간에 일련의 라우터를 거쳐 데이터그램을 전송한다고 이야기했다.
    이 때 경로상의 한 라우터에서 다른 라우터로 데이터그램을 이동시킬 때 데이터링크 레이어의 서비스를 이용하게 된다.

    -  각 라우터에서 네트워크 계층은 데이터그램을 아래 데이터링크 레이어로 보내고, 데이터링크 레이어는 다음 라우터에 해당

        데이터그램을 전달한다. 다음 라우터에 데이터그램이 도착하면, 해당 라우터의 데이터링크 레이어는 받은 데이터그램을 상위
        네트워크 레이어로 올려 보낸다.

• 데이터링크 계층에서 전송되는 데이터 단위를 프레임(frame)이라고 하며, 이 계층에서는 맥 주소를 가지고 통신한다.

• 대표적인 장비로는 브리지, 스위치 등이 있다. (해당 장비들이 맥 주소를 사용한다)

1 Layer : Physical Layer (물리 계층)

• 이 계층에서는 주로 전기적, 기계적, 기능적인 특성을 이용해 통신 케이블로 데이터를 전송한다.

• 물리 계층에서 사용되는 통신 단위는 비트(bit)이며 이것은 1과 0, 즉 전기적으로 On, Off 상태를 나타내는 신호이다.

• 물리 계층은 데이터를 전달하기만 할뿐 수신/발신하려는 데이터가 무엇인지, 어떤 에러가 있는지 등은 전혀 신경 쓰지 않는다.
    단지 데이터를 전기적인 신호로 변환해서 주고받는 기능만 할 뿐이며, 이 계층에 속하는 대표적인 장비는 통신 케이블, 리피터, 허브
    등이 있다.

참고자료

일반적인 웹 서버

• 클라이언트로부터 요청이 오면 가장 앞단에서 해당 요청에 대한 처리를 수행하고 응답을 반환하는 역할

• HTTP 요청을 받아들이고 HTML, 이미지 파일, CSS 같은 정적 컨텐츠를 반환한다.

    -  정적 컨텐츠(html, png, css 등)는 직접 제공이 가능하지만 DB등을 참조해야 하는 동적 컨텐츠는 WAS의 도움이 필요하다.

• 대표적인 웹 서버 : Apache, NGINX

• 정적 컨텐츠가 아니네! 웹서버에서 간단히 처리하지 못하겠군. WAS 에게 처리를 부탁해야겠다
     → WAS가 처리해준 데이터를 받아 와서 Response에 담아 반환

• 정적 컨텐츠구나! 내가 제공해줄게 → html, png 등을 Response에 담아 반환

웹 어플리케이션 서버(WAS, Web Application Server)(앱서버)

• 동적 컨텐츠(DB조회, 비즈니스 로직 처리가 요구되는 컨텐츠)를 제공하기 위해 만들어진 서버

    -  주로 데이터베이스 서버와 함께 가동된다.

• 웹서버와 WAS의 용어 경계가 명확한 것은 아니다 : WAS가 웹서버의 기능을 포함하는 경우가 많음

• JSP, Servlet 구동 환경을 제공하며 컨테이너, 웹 컨테이너, 서블릿 컨테이너라고 불리기도 한다.

• 대표적인 WAS : Tomcat, Jeus, JBoss

    -  SpringBoot 는 Tomcat을 내장하고 있어서 별다른 WAS 설정 없이도 서버를 구동시킬 수 있다.

• 웹서버와 앱 사이의 동적인 정보를 생성하는 역할을 담당하는 미들웨어

    -  웹서버는 앱을 알지 못하고, 반대로 앱은 웹서버를 알지 못한다.

    -  WAS가 웹서버와 앱 사이에서 중간다리 역할을 해주는 것!

    -  예) Tomcat 은 웹을 통해 들어온 HTTP request를 java 언어로 변환하여 앱에 전달하고,
             앱에서 생성된 java 응답을 다시 HTTP request로 변환하여 웹서버로 전달해주는 역할을 수행한다.

WAS 만 있어도 서버 구동은 가능하잖아?

• 사실 WAS와 DB만 있으면 당장 서비스 제공이 가능하다.

    -  WAS는 정적 리소스, 어플리케이션 로직 모두 핸들링 가능하기 때문

• 실제로 API 만 제공한다면 WAS 만 구축하기도 한다.

• 하지만 이렇게 되면 WAS가 너무 많은 일을 담당하게 된다.

    -  앱 로직도 실행해야 되고, 정적 컨텐츠도 제공해줘야 되고…

    -  정작 중요한 어플리케이션 로직이 정적 리소스를 제공하느라 바빠서 속도가 느려진다면?

• 로직을 잘못 짰거나 디비에 오류가 생겨서 WAS가 죽는다면? 오류 화면 조차 확인이 불가능

• 그래서 일반적으로는 client → Web Server(정적 리소스 처리) → WAS(동적 리소스/로직 처리) → DB
    식으로 아키텍처를 구성한다. 그러면 시스템 리소스를 효율적으로 처리할 수 있음.

• 또한 웹서버를 사용하면, 웹서버가 제공해주는 다양한 기능을 활용할 수 있다.

    -  예) NGINX : 동시 접속 처리에 특화된 웹서버 이 밖에 리버스 프록시, 캐싱, 로드 밸런싱, 미디어 스트리밍 등
             유용한 여러 역할을 수행한다.

  웹서버 + WAS의 동작 프로세스

• 클라이언트가 웹 페이지로 요청을 보내면, 웹서버가 해당 요청을 받아 필요한 부분을 WAS에 요청한다.

• WAS(컨테이너)는 web.xml 을 참조하여 해당 서블릿의 작업을 담당하는 쓰레드를 생성한다.

    -  HTTPServletRequest 와 HTTPServletResponse 객체를 먼저 생성한다.

    -  그 다음 서블릿을 호출하고, 생성한 객체를 전달한다.

• 호출된 서블릿의 작업을 담당하는 쓰레드는

    -  Request 에 따라 doPost 또는 doGet 메소드를 호출해 데이터를 먼저 생성한다.

    -  그 다음 이것를 Response 객체에 담아 다시 WAS 컨테이너에 전달한다.

• WAS 컨테이너는 전달받은 Response 객체를 HTTPResponse 형태로 바꿔 웹서버에 전달하고,
    생성되었던 쓰레드를 종료한 다음 HTTPServletRequest, HTTPServletResponse 객체를 소멸시킨다.

• 프록시 서버 (캐싱)

    -  Client와 WebServer 사이에 프록시 서버가 존재할 수 있다.

    -  자주 조회되는 정보를 프록시 서버에 캐싱하면 빠르게 접근할 수 있다.

  참고자료

1. REST(Representational State Transfer) API 란 무엇인가?

REST API의 개념과 등장 배경

• 자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미

• 2000년도 로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개된 개념.

    -  HTTP의 주요 저자 중 한 사람

    -  웹(HTTP)이 우수한 설계에 비해 제대로 사용되지 못하고 있음에 안타까워하며 웹의 장점을 최대한 살릴 수 있는
       아키텍처로 REST를 발표했다.

REST API의 구성요소

• 자원(Resource) : URI로 표현된다.

    -  해당 소프트웨어가 관리하는 모든 데이터(문서, 그림 등)

    -  자원의 표현(Representations) : 그 자원을 표시하는 이름

        ◦  예) DB의 학생 정보가 자원일 때, students를 자원의 표현으로 정한다.

    -  URL과 URI의 차이
       

        ◦  https://agentsmith.tistory.com

        ◦  Tistory 블로그 중에서도 agentsmith의 블로그에 대한 경로를 나타내고 있다.

        ◦  서버에서는 해당 라우팅에 대한 알맞은 자원을 전송해줄 것이며, 자원의 실제 위치이므로 URL이다.

        ◦  https://agentsmith.tistory.com/12

        ◦  agentsmith의 티스토리 블로그에서 12의 ID값을 가지는 자원(포스팅)을 식별하고 있다.

        ◦  https://agentsmith.tistory.com 까지는 자원의 실제 위치이기 때문에 URI임과 동시에 URL이며, /12 부분은 식별자이다.

        ◦  즉 위 링크는 URL(https://agentsmith.tistory.com)을 포함한 URI(https://agentsmith.tistory.com/12)라고 할 수 있다. 

• 행위(Verb) : HTTP METHOD(GET, POST, PUT, DELETE)

    -  데이터가 요청되어지는 시점에서 자원의 상태(정보)를 이용한 행위

    -  JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

핵심정리

• 첫번째  URI는 정보의 자원을 표현해야 한다.

• 두번째  자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.

2. 지키면 좋은 간단한 규칙들

URI Rules

• URI는 정보의 자원을 표현해야 한다.

• 자원 이름은 동사보다는 명사를 사용할 것

• 컨트롤 자원을 의미하는 URI는 예외적으로 동사를 허용한다.

• http://agentsmith.tistory.com/12/duplicate

• URI description 규칙

    -  URI 마지막에  /  를 포함시키지 말 것

    -   _  (underbar) 대신  -  (dash)를 사용할 것

    -  소문자를 사용할 것

    -  행위(method)는 URL에 포함하지 말 것

    -  자원에 대한 행위는 URI가 아닌, HTTP Method로 표현할 것

• HTTP Method

    -  GET(조회), POST(생성), PUT(수정), DELETE(삭제) 등

        ◦  GET /members/delete/1 (X)

        ◦  DELETE /members/1      (O)
       -------------------------------

        ◦  GET /members/show/1  (X)

        ◦  GET /members/1           (O)

• Colllection과 Document을 활용하면 좀 더 직관적인 REST API를 설계할 수 있다.

    -  더 큰 개념으로 생각하면 쉬움. 자원에 대한 부가적인 설명을 나타내는 역할

    -  컬렉션 : sports / 도큐먼트 : soccer

        ◦  예) http:// restapi.example.com/sports/soccer

        ◦  예) http:// restapi.example.com/sports/soccer/players/13

​

HTTP Method Rules

• 하나의 자원에 대해 POST, GET, PUT, DELETE 4가지 methods는 반드시 제공할 것

• OPTIONS, HEAD, PATCH를 사용하여 완성도 높은 API를 만들자.

• HTTP status를 method의 리턴값으로 제공할 것

• 성공 응답은 2XX 로 응답한다.

• 실패 응답은 4XX 로 응답한다. (보통 잘못된 URL 접근시 볼 수 있는 에러)

• 5XX 에러는 절대 사용자에게 나타내지 마라 (보통 DB 또는 코드의 잘못으로 나타나는 에러)

3. RequestParam vs PathVariable vs RequestBody

Path Variable

<https://agentsmith.tistory.com/{id}>
<https://agentsmith.tistory.com/12>

• 개별 자원을 구분하여 요청할 때 많이 사용하는 방법

Request Param

<https://agentsmith.tistory.com/?filter=lowPrice>
<https://agentsmith.tistory.com/?startDate=2022-04-20&endDate=2022-04-25>
<https://agentsmith.tistory.com/?page=3>

• 주로 필터링 또는 페이징을 이용해 자원을 요청할 때 많이 사용하는 방법

    -  필터링  낮은 가격 순으로 보기 / 2022-04-20~2022-04-25 만 보기

    -  페이징  데이터가 너무 많아 한 페이지에 한번에 표시하기 어려운 경우

Request Body

{
   "id": 1,
   "name": "홍길동",
   "team": { "id": 1 },
   "email": "gildong@naver.com",
   "position": "intern",
   "createdAt": "2022-04-22",
   "updatedAt": "2022-04-22"
}

• 새로운 자원을 생성하거나(POST), 자원의 정보를 한번에 수정하고 싶을 때(PUT) 주로 사용하는 방법

• JSON 형식의 데이터를 RequestBody에 담아 보낸다.

4. REST API 설계 방식 엿보기

네이버 오픈 API

카카오 오픈 API

구글 오픈 API

5. 참고자료