통신 : 8bit(1바이트) 단위로
아스키코드
APP / shell로 OS에 명령
OS / 기계어로 하드웨어에 명령
H.W. /
APP-OS 사이의 선이 stream이다
1바이트씩 바이트스트림
자바의 경우 앱이랑 OS 사이에 JVM이 있어서 OS 종류에 상관없이 작동한다
앱에서 OS로 보낸 이후는 내가 신경 쓸 영역이 아니다
앱개발자 입장에서는 내 소켓이랑 상대 소켓이랑 연결되고 스트림으로 연결된다고 생각해도 됨=
outputStreamWriter : OS에 보낼때 배열로 보내서 1바이트씩 안보내고 여러개로 보냄. 근데 배열크기가 고정임
bufferdWriter : 버퍼드 라이트(flush를 해야 os로 내려감)로 보내면 OS가 버퍼드 리더로 읽음
\N(역슬래시n) 끝에 적어야 내려감
IP주소와 포트번호를 알아야 통신 가능함
TCP/IP : 신뢰성 있는 통신
통신을 보내고 응답을 받음
UDP : 신뢰성 없음
보내기만 하고 제대로 도착했는지 확인X
서킷 스위칭 : 전용회선이 있어서 데이터를 한번에 보냄(일반적으로 사용X, 비쌈)
패킷 스위칭 (라우터 공유) : 데이터를 잘게 쪼개서 세그먼트로 보냄(한번에 보내면 나랑 라우터 공유하는 다른 곳은 못보내니까)
내가 라우터까지 보내면 라우터에서 어디로 보낼지 모름(헤더가 필요함. 헤더에 목적지IP와 출발지(내IP) 적음. 세그먼트에 헤더를 적으면 패킷)
또 쪼개 보낸 패킷이 목적지에 도착하는 순서가 보장이 안됨. 쪼개 보낸 패킷을 조립하는 순서를 알아야 함(헤더에 적어둠)
패킷의 바디가 세그먼트
Br ㅡ WebServer(아파치)
사용자가 버퍼드라이터로 (Get IP주소:포트번호/)를 써서 보내면, 사용자 OS의 버퍼드리더가 읽어서 request 보냄
웹서버가 그 request를 보고, 버퍼드리더로 index.html을 읽어서, 그걸 버퍼드라이터에 써서 보냄 (response)
Post로 바디를 적어서 보냈다면, WebServer로 안되니까 WAS(톰캣)으로 보냄
WAS가 Servlet이 있고, Servlet이 request와 response를 가지고 있음
Servlet이
HttpServletRequest, HttpServletResponse를 생성하고
HttpServletRequest에 버퍼를 파싱해서 넣음
init(request, response){
1. 메서드 분석(post get delete...)
2. 바디 파싱
3. DB연결
4. Insert(post였다면)
5. 응답(HTML코드를 BW에 작성)
}
모델1방식
HTML코드를 자바에서 직접 적는게 힘듬
WAS가 템플릿엔진(JSP)를 읽음
템플릿엔진을 서블릿으로 변환해서 실행함
모델1방식 단점 : 단일진입점이 없음.
DB연결,로그남기기 등등 중복되는 부분이 많음.
비지니스로직과 분리되지 않음.
FrontController 패턴 생김
FrontController의 Servlet이 주소를 보고 템플릿엔진으로 연결함
공통처리를 컨트롤러에서 할수있음
컨트롤러가 모델(M)에 DB처리 요청해서 그걸 request에 저장해서 템플릿엔진으로 연결함
또 이렇게 되니까 컨트롤러가 여러개 돼서 컨트롤러마다의 단일진입점이 없음.
스프링부트 프레임워크가 디스패쳐서블릿을 단일진입점으로 만들어줌
디스패쳐서블릿이 리플랙션으로 알맞은 컨트롤러를 찾아줌
