Web

1. OSI와 TCP/IP

1) 물리 계층

: 전기적, 기계적, 물리적 특성을 이용해 데이터를 전달하는 역할.

- 케이블 (전기를 보내 전압차로 0과 1을 전달)

- 리피터 (신호의 조작없이 더 먼곳에 신호를 전달)

 

2) 데이터 링크 계층

: 데이터를 전송 받을 수 있는 두 기계(Node)사이의 연결 계층.

- 각 기계 사이의 데이터를 안전하게 전달.

- 물리 계층의 오류를 감지, 데이터 재전송

- 데이터 전달을 위해 MAC 주소를 사용.

 

3) 네트워크 계층

: Node와 Node는 연결되어 네트워크를 이룸. > 이런 Node의 네트워크 내부의 데이터 전송.

- 데이터의 크기를 조정하기도 함.

** IP (Internet Protocol) : 두 컴퓨터 사이에 연결된 노드들을 통해 데이터를 전달하는 방법을 정의하는 규약.

- IP 주소를 통해 네트워크의 컴퓨터 구분. 

- 데이터가 온전히 전달되는지는 보장X.

 

4) 전송 계층

: 실제로 데이터가 사용자(양쪽 프로세스)가 의도한대로 전송되도록 해주는 계층.

- 데이터가 손실이 있었는지 판단. > 손실 발생하면 다시 보내라고 요청하는 등

- IP 주소를 통해 컴퓨터를 결정하면 > port 번호를 통해 특정 프로세스를 결정.

 

** TCP (Transmission Control Protocol) : 실제로 전달할 데이터를 쪼개고, 쪼개진 데이터가 정상적인지를 판단하기 위한 정보와 함께 패킷의 단위로 보낸다. 

5) 세션 계층

: TCP를 비롯한 전송 계층 통신의 세션을 관리하는 계층

- 두 컴퓨터를 연결/ 연결 제어/ 연결 중단하는 역할

 

6) 표현 계층

: 전달된 데이터를 사용하는 시스템의 형식에 맞게 변환하는 계층.

- 하위 계층에서 데이터를 정상적으로 전송하도록.

- 전송받은 데이터를 정상적으로 해석하도록.

 

7) 응용 계층

: 하위 계층을 통해서 전달된 데이터가 어떤 형태(컴퓨터가 해석할 수 있는 형태)여야 하는지를 정의하는 계층. 

- HTTP, SMTP, FTP...

 

 

2. HTTP (HyperText Transfer Protocol)

: 클라이언트와 서버가 이야기를 나눌 때 주고받는 문서의 양식 같은 것... 

  클라이언트가 요청하면 서버는 응답하는 Client-Server Protocol이라고도 함.

  데이터가 온전히 전달 되었다는 가정하에.

 

1) HTTP Request

Request Line	- HTTP Method, URL 경로, HTTP 버전
Request Headers	- 요청에 대한 부수적인 정보 - 어떤 방식으로 해석해야 하는지 - 어떤 형태의 응답을 기대하는지
Request Body	- 요청을 통해 전달하고 싶은 실제 데이터 - 상황에 따라 생략 가능 (조회 요청 등..)

 

2) HTTP Request Methods

: HTTP 요청이 어떤 목적을 가졌는지 표현하는 동사

- GET : 데이터 조회를 목적으로 하는 요청

- POST : 데이터를 포함한 요청을 보낼 때 (CREATE)

- PUT : 데이터를 포함한 요청을 보낼 때 (UPDATE)

- DELETE : 데이터를 삭제하는 요청을 보낼 

 

3) HTTP Response

Status Line	- HTTP 버전, 상태 코드, 상태코드 메시지
Response  Headers	- 응답에 대한 부수적인 정보 - 어떤 방식으로 해석해야 하는지 등
Response  Body	- 요청을 통해 전달하고 싶은 실제 데이터.

 

4) HTTP Status Codes

: HTTP 요청의 처리가 어떻게 되었는지 알려주는 상태코드

- 100~199 : 정보 제공 목적 (개발자가 사용하지 않고, 컴퓨터 사이에 사용)

- 200~299 : 요청이 성공적으로 처리되었음

- 300~399 : 요청의 처리를 위해 클라이언트의 추가적인 행동이 필요 (redirect)

- 400~499 : 클라이언트가 처리가 불가능한 요청을 한 경우 (400, 401, 403, 404)

- 500~599 : 서버에 문제가 생겨서 처리가 불가능해진 경우 (500)

 

 

3. Java EE와 Spring

- Web Server   vs.   Web Application  vs.  Web Application Server 

 

1) Web Server : 사용자의 HTTP 요청을 받고, 해당 요청에 해당하는 파일(응답)을 돌려주는 서버.

2) Web Application : 웹 서버 상에서 실행되며 웹 서버가 전달한 요청에 따라 알맞은 응답을 생성해내는 응용소프트웨어(=어플리케이션) 웹 서버를 통해 사용자의 브라우저에서 활용할 수 있도록 하는 것! (직접 요청을 받아 응답할 수 있는 능력은 포함X)

3) Web Application Server : 그냥 Web Server를 내장시켜서 바로 실행할 수 있도록 하자... (웹 서버 + 웹 어플리케이션) 브라우저를 통해 접근한 사용자에게 특정 서비스를 제공하고, 이를 위해 필요한 HTTP 요청 등을 듣는 기능을 내장시킨 것.

Web Server                                                             Web Application                                             Web Application Server

 

 

- Java 웹 개발의 역사

1) Java Servlet의 등장과 함께 동적인 페이지를 제공하는 기술 등장 - WAR 형태의 압출파일을 웹 서버에 전달. 

- WAR에는 웹 서버가 HTTP 요청을 받으면 활용가능한 자바 Servlet의 구현체가 있고, 개발자는 이를 직접 작성하고 web.xml을 이용해 웹 서버에게 어떤 요청이 들어왔을 때 어떤 자바 Servlet을 사용할지를 정의해줌.

// HttpServlet.class
public class MyServlet extends HttpServlet {

    @Override  // get 요청이 왔을때 실행할 메소드
    protected void doGet(HttpServletRequest req, HttpServletResponse res) 
        throws ServletException, IOException{
        // 여기에 코드 작성
    }
}

// web.xml
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_4_0.xsd" version="4.0">

  <!-- 이런 Servlet이 있다 -->
  <servlet>
    <!-- 이런 이름으로 부를거고 -->
    <servlet-name>MyServlet</servlet-name> 
    <!-- 실제 클래스는 이거다. -->
    <servlet-class>com.example.MyServlet</servlet-class>
  </servlet>

  <!-- 이제 요청에 어떤 Servlet 쓸지 알려주겠다. -->
  <servlet-mapping>
    <!-- 위에 말해둔 그 Servlet이다. -->
    <servlet-name>MyServlet</servlet-name>
    <!-- `/myservlet`으로 요청이 오면 써라. -->
    <url-pattern>/myservlet</url-pattern>
  </servlet-mapping>

</web-app>

 

2) Spring MVC의 DispatcherServlet : 하나의 HttpServlet에서 모든 요청을 받고, 개발자가 정의한 POJO에게 요청을 위임.

// Servlet 대신 @Controller만 작성하면 된다.
@Controller
public class DemoController {

    @RequestMapping("home")
    public String home() {
        return "index";
    }
}


// web.xml
<web-app>
	<servlet>
    <servlet-name>dispatcher</servlet-name>
    <!-- Spring MVC가 제공하는 Servlet 쓰겠다! -->
    <servlet-class>
        org.springframework.web.servlet.DispatcherServlet
    </servlet-class>
	</servlet>
	
	<servlet-mapping>
    <!-- 모든 요청에 대해 그 Servlet을 쓴다! -->
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
	</servlet-mapping>
</web-app>

 

3) SpringBoot의 등장 : HTTP 요청을 받을 수 있는 웹 서버를 스프링 프로젝트 내부에 내장시켜 만들어진 산출물을 웹 서버 없이 실행할 수 있도록 함. >> 복잡한 xml 기반 설정에 얽매이지 않고 자바 언어를 이용하여 개발과 설정 파일(.properties/ .yaml)에만 신경쓰며 비즈니스 로직에 집중할 수 있게 되었다.

 

@SpringBootApplication
// @EnableAutoConfiguration이 본래 Spring에서 설정해야 되는것들을
// 기본값으로 설정해준다!
public class DemoApplication {

	  public static void main(String[] args) {
		    SpringApplication.run(DemoApplication.class, args);
    }
}