wiki에 팀 룰 등 작성
issues 에서 단계별 작성??
project에서 전체 프로젝트 이름.. basic kaban
이슈를 프로젝트에 할당하기
하나의 아이템을 이슈에 넣을수도 있는데 나중에 추가할수도 있다. 애자일한 것이니까. 룰도 그라운드 룰이지엄격한 룰이 아니다. 방향 설정을 할뿐 지키느라 싸움이나면 지킬 이유가 없다.
이슈는 기능 단위인데, 우리가 구현할 수 있는 단위로 적으면 좋겠다. 이슈하나가 풀리퀘가 되는 것.
풀리퀘를 우리가 프로젝트 안에서 머지해야한다. 기능 구현후 리뷰어에게 요청하고 싶으면 main저장소에 풀리퀘 보내면 된다. 그 전에 로컬리뷰 거치는게 좋다.
프로젝트를 honux77/java-was-1에서 풀리퀘를 만들어서 내저장소에서 내 저장소로 풀리퀘를 보내야한다.
풀리퀘는 리버트가 가능하다. 풀리퀘 커밋들을 통째로 취소할수있다. 그래서 1인프로젝트할때도 풀리퀘 버릇 들이는 것이 좋다.
gitflow는 안드, ios등 같은 파일의 다양한 버전이 필요할 때 사용해야하고, 단일 워크 플로우일땐 안쓰는 것을 추천한다.
프로젝트 협업 브랜치를 settings에서 만들어서 그걸 메인으로 써라.
1) 웹서버는 멀티쓰레드이다. 싱글스레이일경우 오래 걸리는 요청이있으면 그것을 다른 사람들이 기다려야한다.
멀티쓰레드는 단점 매번 쓰레드 생성/제거, 그래서 concurrent thread pool을 한다.
- 요청(request)리퀘스트 분석
- response 만들기
언제나 똑같은 output을 내놓는 동일한 사람은 쓸수없다.
2) 멀티쓰레드말고, 싱글쓰레드 비동기 방식이 있다.
사용자가 서버에 요청(request) 보내면, Node.js가 EventLoop에 리퀘스트를 담는다. 그래서 이벤트 큐에 이벤트들이 쌓이면, eventlooop에서 검사해서 처리해서 응답한다.
워커쓰레드가 따로있다.
1)2)중에서 동일한 cpu에서 2)가 성능이 좋다. 쓰레드 생성/삭제 오버헤드가 없고, IOCPU? overhead?가 없다. network, disk IO가 성능 저하하는데, 얘는 CPU하나밖에 없다.
실제로 node.js를 한개의 CPU에서 비교하면2)가 빠른데, CPU까 멀티 CPUaus 1)이 빠르다. 그렇다면 Node.js를 코어 개수만큼 띄우는게 가장 빠른 솔루션이고, 실제로 이렇게 한다.
(웹플러스도 이런 방식으로 돌아간다.)
기본적인성능은 Node.js 프레임워크가 좋지만, 개발자의 실력은 Spring java가 좋기 때문에 기업에선 Spring을 많이 쓴다.
우리가 8080으로 접속하기 때문에 서버는 포트 8080을 열고 대기중 상태가 된다. 사용자가 서버로 들어가면 tcp커넥션이 생성된다.
tcp커넥션이란 뭘까?
브라우저도 임의의 포트를 항상 가지고 있다. 높은 번호의 포트.
포트는 논리적인 통신채널이다. 그런데 브라우저를 하나 열떄마다 포트가 하나씩 할당된다. 클라이언트에게 랜덤 포트가 할당된다.
아무튼 8080으로 접속을 하면, 다음 사용자는 8080포트를 사용중이다. 8080은 요청 대기용으로만 사용되어서, 사용자가 와서 tcp/커넥션에서 3way connection으로 핸들을 해주면, 처리용 포트를 무작위로 만들어낸다. 임의으이 포트 생성한다.1번은 커넥션을 서버 끊어질때까지 5000사용하다가 2번 사용자가 오면 8080으로 접속하고, 들어오고 나면 서버는 2번사용자를 위한 새로운 커넥션을 만들어낸다. 메인쓰레드는 이 중에서 대기하는 것밖ㅜ에 안한다. 연결을 만들어내는 것은 ㅁ커넥션을 만들어내는 쓰레드 n번에서 새로운 포트 만들어서 커넥션을 생성을하다가 끝나면 다 죽고 사라진다.
대기하는 역할을 담당하는 것이 컨트롤러와 비슷한데, 더 앞단의 서블릿 컨테이너의 역할이다.
한번에 한사람만 8080에 요청가능한 것이고, 여러명이 번호표뽑는 기계 앞에서 기다리는 것처럼,, 무한히 많은 지원이 있기 때문에 대기가 발생하지 않는데 실제 웹서버에서는 요청이 많기 때문에 쓰레드 많이 만들어도 처리가 불가능하다. 쓰레드 개수는 컴퓨터 코어 개수 이상 못 만드니까 ..
수강신청할때 서버 다운되는 이유는, 디비가 느리기 떄문에.
그래서 웹서버에게 일을 더 많이 시키는게 좋다. 웹서버가 더 싸고, 수평확장이 쉽기 때문이다.
네트워크 웹서버는 탐캣과 스프링이 추상화해주기 때문에 우리는 애노테이션만 달아주면 다 쓸 수 있따..그렇게 중요하지 않을 수 있따.. 웹서버 다 공부하면 jsp를 공부해주면 된다. 면접떄 유용하고,, 서블릿이 아직 죽지 않고 백단에서 열심히 돌아가고 있는 것이기 떄문이다.
소켓이란? 네트워크 통신을 추상화한 통신수단. ipc라고 inter processor communication을 위해 만들었던 것 중 하나가 소켓이다. 유닉스 초창기에 프로세스간 통신을 위해 만들어진 것 중 하나가 (소켓 말고) 파이프가 있다. 파이프는 (ls | grep hello)에서 |가 파이프인데, 프로세스 간 통신수단이 이유가 ls와 grep가 통신하는 것이다. ls의 결과가 grep의 인풋이 되기 때문이다. 한편 파이프는 단방향 통신수단인데, 프로세스가 단방향 통신하는 원시적 수단이다.
반면 소켓은 양방향 통신수단으로 서로 메세지를 주고받는 것이 가능하다.
무전기는 half-duplex (반이중) 통신수단으로 말하는 동안은 수신이 안된다. 양방향이긴 한데, 통신 채널이 무선 전파가 한번에 한명만 발신할 수 있다. 듀플렉스는 양방향이기 떄문에 듀플렉스고, 한번에 한쪽밖에 안되니까 하프 듀플렉스다.
휴대전화는 동시에 말하는 것이 가능하므로, full-duplex이다. 실제로 쓰는 것은 반이중에 가까워도(한번에 한명만 말하니까) .
소켓은 full-duplex를 지원하는 프로세스를 어쩌고...
ServerSocket listenSocket = new ServerSocket(port)
listenSocket은 용도가 공공용, 듣는 용, 송신 대기용이다. ServerSocket은 서버 용도로 쓰여서 서버 소켓이다.
Socket connetion;
while((connection = listenSocket.accept()) != null)
대기상태이다가, 클라이언트가 접속하면 true가 된다.
루프를 돌며 서브 소켓을 만들고 8080으로 대기중, accept 준비를 한다. 사용자가 8080으로 리퀘스트를 보내면, 소켓이 하나 더 만들어져서 이 소켓과 사용자가 연결된다. 이 연결된 소켓에서 별도의 쓰레드에 만들어서 역할이 input stream과 output stream을 만들어서 request로 들어가서 response로 돌아간다...???
