Sorry bro that is not possible...
You can not differentiate if someone wants to download or upload data as long as every connection is started by a client from your lan.
You can realize that all connections that are started from outside have to go through wan1 and all connections from inside your lan go through wan2.
But nothing more.
To further @juppin, when a connection is initiated: packet sent from your LAN to the internet. There is just the initiation handshake... The router needs to decide which WAN to send this initiation out of based on the very first packet sent. Once it's sent from that IP, the connection is locked in and there's no way to change the source IP address while the remote machine continues to know what the heck is going on.
So, if your LAN client wants to upload something to say Google Drive, you have to decide on which WAN to send the initial packet out through, even though the router doesn't know whether your LAN client wants to UPLOAD a file to Google Drive, or DOWNLOAD a file FROM Google Drive...
The only point at which you can distinguish these two cases is later after a second or so of packets, if you've either sent more than received, or received more than sent... but it's too late at that point.
For the sending side, you should be able to control this, but for the receiving side you need help from your ISP(s). In theory such differential routing is possible, but in practice I am unsure whether any normal end-user oriented ISP is going to play ball....
And how do you want differentiate that on a tcp connection?
+1, as I said "for the receiving side you need help from your ISP(s)". Possible, but highly unlikely.
Even better, OP could try to explain, why he desires this setup in the first place. I could think that with fixed wireless links, it might be helpful to simply drive each uni-directional instead of half-duplex bi-directionally, but this is pure guess work.
No, if he always wants to send on one interface mwan3 should be his friend (https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3), the catch I see is that for the ingress side his ISP would need to steer all packets to the other interface. I believe that to be possible (not sure about NAT masquerading though), albeit tricky. But again, my bigger question would be what underlaying problem exists that makes the OP think about such a set-up?
But for a regular download with a tcp connection i have to first send something and the server does answer to this ip... Rewriting the ip from this destination address to another is very bad... And how should the rewriter determine if it´s a download or a upload?
I´m not familiar with mwan3, but i think it´s main goal is to balance all the traffic over all available wan connections.
Well, routing between AS also does not use the same paths/peering points in both directions, so assymetric routing per se is not the issue. The challenge is that you need a) more than two NATed IPv4 addresses for your network, and an ISP that treats you more like an AS than as an end-customer.
My point is not that this is easy or suitable for the typical end-user link, but that in theory it is possible.
But as long as the OP does not elaborate on the why, I will try to reduce the amount of theoretical observations I inject in this thread 
As far as I can tell it should be possible to use that to steer all outgoing traffic over one interface, but again the tricky thing outside his control is the rverse path, where his ISP or even ISPs would need to perform the traffic engineering that all packets destined for his network take a router via the other interface.
If not mistaken some SAT routers implement such feat, splitting up and downloads between SAT link and terra link. But then it is the same ISP that handles the split routing in their back-end.
This has nothing to do with this topic as routing doesn´t change the packages beside the ttl field.
In theory everything is possible in my world. So i agree.
What the OP wants packets leaving via one path and returning via another is very much assymmetric routing between his network and his ISPs, and that is know to work without IP rewriting. But then most likely not for a typical end-user link without its own pool of IP addresses.
Sure, but this case assymmetric routing between autonomous systems is how the core of the internet works, so the solution is not as exotic as you make it belief, at least theoretically, I bet that for the OP's link assymmetric routing might as well be made out of unobtainium
I totally agree with you.
You are right 
In general it should be achievable with an app like bird and BGP peering but the issue is more likely the remote server acting on different IP's in the TCP session
Well (almost forgot), there is however MPTCP [1 | 2 | 3] (not sure about UDP)
MultiPath TCP (MPTCP) is an effort towards enabling the simultaneous use of several IP-addresses/interfaces by a modification of TCP that presents a regular TCP interface to applications, while in fact spreading data across several subflows.
[1] https://multipath-tcp.org/pmwiki.php/Main/HomePage
[2] Help me build OpenWrt with MPTCP?
[3] https://tools.ietf.org/html/rfc6824
You can't split layer 3 across interfaces. The other end of the link would not understand.
Just a guess: It sounds like you want load-balancing, or link aggregation.
The simple answer may be to buy a load-balancing device designed to spread load across multiple paths.
Do you want your upload to not be affected by other traffic (download)?
If your upload is important only to a certain destination, then just have default route via wan1, and add a separate route for your destination via wan2.
If you upload to random destinations, have a script running in the background that periodically (like every sec) measures the traffic load on each WAN and bounce the default route when there is considerable traffic load on the current exit WAN. For example, if at a certain moment current default route exits via wan1, and wan1 has 10 Mbps load while wan2 has 0.1 Mbps, then switch default route to exit via wan2, so the next TCP connection will exit through wan2. You get the idea.
All the script has to do is to parse the TX bytes and RX bytes from the output of ifconfig, and modify the default route with ip route.
I have 2 ip on same wan can i still achieve that and i upload ro random destination
Ok ...
So I assume you are currently using only one of the 2 IP addresses for the uplink, they share the same gateway, and the bottleneck is not in your physical network. I'm also gonna assume you know what you are doing.
In that case you can make a script that bounces between:
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 1.x.x.x
iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 2.x.x.x
and use conntrack -L (install conntrack) to measure bandwidth used by each IP.
Or you can create a second wan logical interface using the same physical interface, eth1, and put the second IP on that second logical interface. Then, you can install mwan3 and mwan3-app-luci, and play with that. Never used it myself.
What is the reasoning behind choosing different source IPs for different uploads considering that they both travel over the same physical link? Is this a kind of privacy thing, or in order to appear to be from a single server like for load balancing?
It seems unlikely that you will get any performance boost, unless perhaps the ISP has a per-ip-address traffic shaper, and they have given you two different IP addresses so you have two different shapers. If that's what you're trying to do, then I suggest mwan3 approach.